Re: GOOPS plans

[Craig Brozefsky <craig at red-bean dot com>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> While LISP is "centered around" symbols, Scheme is centered around
> objects.  Because of this, the GOOPS MOP will change to also be
> centered around objects.  E. g., slots will no longer be identified by
> a name, but by a slot definition object.

I don't quite understand the distinction between symbols and objects
that you are making above.  I can think of several different ways of
intepreting the comment, but am not sure which one you mean.  Are you
talking about the use of symbols as slot-names in CLOS, where in
TinyClos any object can be used as a slot-name?  Are you thinking that
CLOS uses symbols as opposd to slot-definition-objects to define
slots, which is not true, as symbols only name slots and you can
actually update slots wihtout knowing their name if you use the MOP.

CLOS has slot-definition objects as well, which are contained in an
instance of the metaclass for a given class.  Each one of these slot
definitions has a name, which I believe must be a symbol(never tried
using string or other things as names).  These are not passed around
tho, and the slot-value and (setf (slot-value ..))  mechanisms use the
names to reference slots, so (slot-value someinstance 'slotname)
expands into:

(slot-value-using-class (class-of someinstance)
                        someinstance
                        (find-if #'(lambda (d)
                                     (eql slotname
                                          (mop::slot-definition-name d)))
	                (class-slots (class-of someinstance))))

Oversimplified and untested, but you prolly get the gist.

> This means that slot-ref/set! *will* be outdated.  (They are going
> to be supported in the STklos compatibility module, however.)  I
> know that this is a bit controversial, but we have already had a
> long discussion about this in the past.  While that discussion
> didn't end in consensus, the support for this change was stronger.
> After long consideration, the decision is now made to carry it
> through.

Am I correct in quessing that slot-ref and set! will operate much like
the slot-value example I gave above?  If so, then why are they going
to be outdated?  Will we no longer be requiring slot-defs to have a
name?

How would you handle class redefinition with these slot-definition
objects?  Are we passing around slot-def objects in our accessors and
readers?  Can users manipulate these objects?  If so, how do we make
sure they are all updated when their class is redefined?  If these are
available to the user then we can redefine the methods for each
accessor, but if they are not available then we need amethod to make
sure they all get updated when a class is redefined if we are gong to
support class redefinition.

PS: I'm not voicing opposition to this decision, but trying to figure
out what decision was made.

-- 
Craig Brozefsky                      <craig@red-bean.com>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli