This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Some questions about GOOPS and CLOS in general


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

> The responsibility of administering names is left to the module
> system.

I think this is the right answer to the multiple-slots-with-one-name
problem.  But note that the module system does not administer slot
names, but only variables (unlike thew CL package system which deals
with symbols and thus with any kind of name space that CL has).

I'm getting slowly convinced that the package system of CL isn't that
bad, precisely because it works on the symbol level.  You can handle
all kind of name spaces with it, not just top-level environments.

It is a different questions whether you want to have the many name
spaces of CL.  Personally, I like to have a unified name space for
functions, variables and classes.  But I also start to think that
having just _one_ name space for everything is not realistic.  I don't
think one wants to put slot names into the same name space as
functions and variables, for example.

> > Or we might remove `slot-ref/set!' entirely (or, rather, deport them
> > to the stklos compatibility module) and by default generate an
> > accessor for the slot. [...]
>
> I think this is a good idea myself, but I had expected reactions to
> this.  Since no people have complained, I might actually go about
> removing slot-ref and slot-set! in release 0.1.4.

Hmm, I agree that using slot-ref and slot-set! in `production' code is
probably not very important, but there should be a way to get at slots
without an accessor or without knowing what funky name an accessor
has.  That is, slot-ref and slot-set! might need to be extended to
take the class as an argument to disambiguate what slot is referred
to.

Or, one could entirely dispose of slot _names_.  That is, there
wouldn't be any named slots but just accessors that use some
behind-the-scenes-magic for their implementation, but for the user
there isn't such a thing as a slot.  The MOP would not talk about
slots either, only about accessors.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]