Re: Some questions about GOOPS and CLOS in general

[Mikael Djurfeldt <mdj at thalamus dot nada dot kth dot se>]

Craig Brozefsky <craig@red-bean.com> writes:

> Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:
> 
> > Marius Vollmer writes:
> >  > 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.
> >  > 
> > That's also my preferred solution, slots working like free variables
> > in a closure.
> 
> Then I need to have accessors defined for all of my slots, even ones
> that just contain computed values, or any other slots that I would not
> wanta getter or setter for.

Well, there seems to be two cases here:

Either you want an accessor (read/write) which is the standard case,
or you want a getter (read only).  The only setter case is equivalent
to not having the slot at all.

The syntax I suggested earlier for dealing with read-only slots is:

  (x #:default-accessor #f #:getter x)

But a better syntax would be

  (#:getter x)

i.e., we simply omit the name in the car.  In this way, you could
regard

  (x)

as shorthand for

  (#:accessor x)

What is your concern with having accessors/getters for all slots?  Why
is that a problem.  (Actually, in the example code I showed, most
slots had accessors.)

> Also, how would I specialize the accessors in this to do more than
> just set the value or get the value?  What if I wanted them to do
> some transformation on the value?

The most obvious solution would be this:

  (define-class <c> ()
    (x' ...))

  (define-accessor x)
  (define-method x ((o <c>))
    ... do something ...
    (x' o))

You can also use the MOP (compute-get-n-set) or the metaclass
<active-class> defined in active-slot.scm in the GOOPS distribution.

I guess you are worried about not being able to use `slot-ref/set!' in
these non-standard accessors.  Actually, if you are using
`compute-get-n-set', you can't do that in the current GOOPS or in STk
either, because slot-ref itself uses the getter/setter computed by
`compute-get-n-set'.  In active-slot.scm, this has been solved by
using low-level accessors %fast-slot-ref/set! (inherited from STk).
If we remove slot names, these will also be removed, but there will be
similar low-level accessors (standard-instance-access) which use the
"location" of the slot instead of the name.

I don't see in what way slot-ref/set! would provide better or cleaner
solutions to this problem.

> What intelligible identifier would I have for code that is
> attempting to document the class for me, or otherwise use the
> reflection built into the MOP? What the standard-slot-definition or
> whatever it is called in GOOPS have a name slot?

I think this is a crucial point.  It is important that the MOP can
work smoothly without slot names.  I did some preliminary examination
before proposing to remove slot names, and I think it can.

I actually see no reason, in principle, why the MOP would need to
identify slots using names.  The slot-definition itself will take over
the role of the slot identity.

Of course, if we want to be able to support slot merging, names are
required.  But if this support is limited to the (oop goops stklos)
compatibility module, it is enough if stklos-slot-definition:s have
names.

Another reason to keep the name in slot-definition:s could be
debugging.