[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Details in a-to-c spec
- To: gregor@parc.xerox.com
- Subject: Details in a-to-c spec
- From: jac@computer-lab.cambridge.ac.uk
- Date: Tue, 24 Jul 90 11:27:07 +0100
- Cc: MOP.pa@Xerox.COM
- Sender: jac@computer-lab.cambridge.ac.uk
From Richard Barber, Procyon Research Ltd, Cambridge, UK
Thinking in more detail about the a-to-c spec:
1. What is an 'effective method option', in the description of
compute-effective-method?
2. Further down in compute-effective-method, it says
>Because neither method nor method combination metaobjects can be
>reinitialized, the results of this generic function may be memoized.
Does this mean that a method combination may not depend on side-effects
(e.g. the value of a special variable)? If it could, then the results of
this generic function may not be memoized. On the other hand, if a method
combination may not depend on side-effects, then this needs to be stated
near the beginning of the CLOS spec.
3. Have you gone through what happens when a slot-definition class is
redefined? If the slot structure of the class changes, then
update-instance-for-changed-class gets called on each slot-definition
instance. Update-instance-for-changed-class in turn may call the
standard-slot-definition method on shared-initialize. However, the section
'Initialization of Slot Definition Metaobjects' that I have here states
that 'if the :name argument to this method is not specified an error is
signalled'.
Is this your understanding of what the behaviour should be? Surely it
should be possible to redefine a slot-definition class without causing
an error?
4. Finally a comment about the proposed MOP generic functions on
structures:
>"Richard P. Gabriel" <rpg@lucid.com>, Fri, 22 Jun 90 22:49:06 PDT
>
>I would very much prefer to leave out structures as much as possible
>from this protocol. Structures are very nice as they are, and I fear
>the possible slowdown of structures or incorrectness and complexity of
>implementation in order to accomodate the MOP. The complexity of
>implementation is not justified for the simple facility.
I agree. Structures should be left out of the protocol. Otherwise, users
of the MOP get little more than an extra bit of syntactic sugar, and the
implementor has a real struggle to get it working correctly.
Richard