Re: Some questions about GOOPS and CLOS in general

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

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> * The interface seems rather strange to me. For example
>   GOOPS uses getter and setter functions to access slots.
>   A more "natural" way would be:
>   (<class> <constructor> args) -> <object>
>   (<object> <feature>) -> get value ("getter")
>   (<object> <feature> args) ->  set value ("setter")

Natural is a POV issue.  Coming from a CLOS background, I find the
generic function mechanism more natural.  I have worked with several
languages which use the syntax above, and I must say that I am not
impressed.  First, when I'm scanning code I usually know what object
it is operating on, so it's nice to have the getter/setter appear
first, because that is the pertinent peice of information for me.
When writing code, I do not need to know how many methods it will take
for me to get to the object I want to act on when I start writing the
form.  For instance, in ObjC:

[[[obj getter1] getter2] whatIwantedtodo]

The Three opening braces have to be typed first, or I have to jump
back to the beggining of the form and fill them in, and then step thru
the form and make sur eI got the count right.  I just spent ht elast 6
months doing ObjC, and this is a pain.  Whereas with the generic
function syntax I would do this:

(whatIwantedtodo (getter-method2 (getter-method1 obj))) which rolls
off the kbd much easier, and requires no jumping back to the start of
the form, or knowing how far away the object I want to act on is.

Those are minor issues, and I don't think they make a really strong
argument for why the generic function syntax is preferable, but there
are indeed stronger points.  The most pertinent is that the
getter/setter syntax you use above expose the structure of the class
to me, by making it explicit that a value is a slot, and not just a
computed value.  Whereas with the getter/setter as generic functions,
our code does not have to know if its an attribute or now, plus we can
use multi-dispatch in our getter/setters using the same defmethod
syntax for specialization that all our other methods use.  Granted we
could hav something like this with the syntax you denote above, by
making objects lambdas, but we would still have the distinguishing
interface.

Lastly, this object centric stuff doesn't really float in a
multi-dispatch OO system.  Once you get used to multi-dispatch and
generic function there is no going back. IMO. YMMV.

> * In CLOS classes don't own (polymorphic) methods.  Instead
>   it is possible to associate a polymorphic method called "generic"
>   to a class.  The problem is, that it is not possible to
>   "ask" a class about the methods it supports.  For example
>   if you want to write a class that stores itself onto 
>   a persistent store, the class has now way to store the
>   methods associated with it.

This is not a problem at all, this is simply a confusion about the
role of "objects" in CLOS like system.  In a generic function world
there is no notion of objects owning methods.  What you are defining
instead of classes with associated methods, are datatypes and
protocols.  It's sorta like abstract classes in the cableTV
set-top-box language, except that there is no formalized way to define
what is in a particular protocol.

To solve the persistent store issue, remember that generic functions
are objects themselves, so you would store them on their own, if you
wanted to have a set of associated generic functions stored and
versioned with the objects you slap into the store, you could simply
add a attribute to the class metaobject for persistent objects which
could hold a list of generic functions which should be pickled along
with the object.

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