Re: Some questions about GOOPS and CLOS in general

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

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

> 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.)

Because I use the accessor/no-accessor distinction on slots to
indicate what slots are supposed to be part of the interface for that
class.  When I export to other modules I can choose to not export the
accessors for various slots, but when working in that module I
obviously cannot use the module system to help me define the class
interfaces.  In other words, within the module that a class is
defined, I use the presence and lack of accessors for a slot as a way
of defining the interface for that class for code that is in that same
module.  I think this makes it easier for others to add patches and
modify the module.

> > 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))

With that solution I have to tweak my slot names, something I'd really
rather not do.  At that point you might as well just tweak them for
me, defining an accessor "slotname'" and a method "slotname".  I could
redefine the "slotname" method.  But doing that just seems ludicrous.

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

Yarch!

> 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.

It's not the MOP I'm worried about, it's the programmer.  The idea you
posted shortly after making this post where you added a #:name option
just seems to re-introduce the name, but makes it optional, which
means that I cannot rely on it being their when I'm building my
reflection tools, like SQL table schema generators and the like.  I
think it very useful to have names to identify slots in a class, and
that they should be mandatory (at least in the standard slot defs).

As for your previous question of why slot-value/slot-ref is a cleaner
solution, I think it is because they present a distinct interface
which indicates to anyone reading or writing code that that slot
reference is bypassing the defined API.  If we just rely on the
exports of accessors to define our APIs, we are limiting the users
ability to go beyond our API if a need arises, and we are also making
it difficult for users to identify where they have done that.  If we
had a mechanism for referencing unexported symbols we would not have
the first problem.  But the second problem is dependent upon a
distinct syntax.

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

Or any other type of reflective programming task.  It seems like we're
throwing away a useful bit of information for a kinda dumb reason (a
limitation in our present reader).

Thanx for your response Mikael, and all of your work so far, please
take my disagreement as freindly cooperation to make GOOPS as good as
possible, and not griping about your work.

I'll be unable to respond most likely for the next few days, but am
looking forward to your comments.

-- 
Craig Brozefsky                         <craig@red-bean.com>
Free Scheme/Lisp Software     http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle 
 prods and the IMF." - Radiohead, OK Computer, Electioneering