This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: GOOPS plans
Craig Brozefsky <craig@red-bean.com> writes:
> 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?
No. Slots won't have names in the sense they have now. The slot
definition metaobject will overtake the role the name had before.
(But, in most cases, a slot definition metaobject will have a name
slot, which will be used for printing and debugging.)
> 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.
[...]
No, the slot definition metaobject in GOOPS will have the roles of a
CLOS slot definition object, but, in addition, most of the roles of
the slot name. I.e., arguments to MOP procedures which currently is
the slot name will in the future be the slot definition instead.
However, references to slots will be taken over by the accessors.
> (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?
Yes, the slot-ref and slot-set! in the STKlos module will have that
semantics.
> If so, then why are they going to be outdated? Will we no longer be
> requiring slot-defs to have a name?
No. The role of the name to identify a slot will be removed. The
role of the name as identifier for the stklos metaclass is strictly a
property of that metaclass.
Also, as consequence, slots will not be merged at inheritance. We
will be able to support merging, though. For such slots, some means
of identification, using name, accessor, or, something specific to
that mechanism, will be employed.
> How would you handle class redefinition with these slot-definition
> objects?
By comparing the structure of the slot definition metaobjects. In
this particular case, we probably will use the accessor object as a
primary means of identification.
The change certainly makes the class redefinition protocol less
well-defined, but I still think it is useful enough that we should
remove it.
> Are we passing around slot-def objects in our accessors and readers?
No.
The slot access itself is performed through a primitive get/set
functions which are carried by the slot definition object. E. g., the
get function of the standard accessor method is
(lambda (O) (@slot-ref O INDEX))
The method compiler will replace most calls to accessors with the
@slot-ref form, but even without method compilation, standard slot
access is O(1).
> Can users manipulate these objects?
(I assume you mean change their state.) Many (perhaps all) slot
definition object accessors will be read-only.
> If so, how do we make sure they are all updated when their class is
> redefined?
I'm not sure about this one, but, probably, when the class is
redefined, new effective slot definition objects are created. This
means that the old ones have to be invalidated. (Otherwise, we open a
way to crash Guile.)
> PS: I'm not voicing opposition to this decision, but trying to figure
> out what decision was made.
Sorry, I don't have time now to specify details.
My intention with the letter was just to send two signals:
1. that people shouldn't worry that I suddenly introduce some crazy
GOOPS-module system mechanism, and,
2. that people shouldn't rely on slot-ref/set! in their code.
Generally, while people can rely on most basic GOOPS mechanisms, the
MOP will be very unstable until the major version number moves from 0
to 1.
/mdj