[plt-scheme] Re: Swindle CLOS ?

On Mar 10, Kyle Smith wrote:
> Eli Barzilay wrote:
> > No, I just said that I personally don't see any sense in doing that
> > (adding a `ColoredPoint-x' accessor in your example) which is why I
> > didn't do it at the time.  It only defines accessors that are
> > syntactically part of the definition -- for example:
> >
> >   (defclass Point () x y :auto #t :print #t)
> >   (defclass ColoredPoint (Point) x y color :auto #t :print #t)
> >
> > will give you a `ColoredPoint-x' that is independent from `Point-x'.
> > (The whole auto-accessor thing is my own thing, BTW, so there's no
> > CLOS tradition to follow there (IIRC, at least).)
> Hi Eli,
> 
> Thats pretty impressive to have come up with that on your own, it
> sure works nicely.  Oh, before I forget, you should probably update
> your doc right about the section that your discussing keywords and
> the different auto settings to mention that the format of the
> keyword is to pre-pend a ":" to the slot name.  To get that piece of
> information I actually had to do a search on :autoinitarg in your
> source to find out how it was being constructed.

Done.


> After I found the information I noticed that you use keywords with
> colons in front of their names in a few places that I happened to
> stumble upon, but to my knowledge there is nothing the explicitly
> states this fact.  It would be a real time saver for a newbie.

(That's very common in CL, and therefore in CLOS...)


> I gave some more thought to this ancestor accessor issue, and I came
> up with an argument that someone might use in defense of Meroonet's
> position.  When we build a derived class in a module, it may be the
> only class that is in our interface.  So if I had built a module to
> handle ColoredPoints, I would want the abstraction to be complete
> with its own accessors to all ancestor slots as well.  Now I know
> that they are implemented as generics as you said, so they don't
> really belong to the class ColoredPoints, but from an interface
> perspective they appear to belong to ColoredPoints, and thats the
> beauty of the naming convention.  The user need know nothing about
> how ColoredPoints is actually implemented as two classes.  All they
> see is a single unified class that gives them access to everything
> the need to work with ColoredPoints.

I actually view this as an argument for not having these accessor
names generated: there is no reason to have a `ColoredPoint-size'
accessor since the `ColoredPoint' class definition has nothing to do
with implementation details that are related to size except for
inheriting it.  But -- if you do specify a size slot, then you want to
have an accessor too, regardless of whether the slot exists in the
super class or not.  But this is subjective -- YMMV, of course.


> If I could crack that nut then this whole thing would be academic,
> because I could just define the methods after the class was defined.
> I thought at first that begin-lifted, from etc.ss would help, but it
> only works with expressions as it terminates definition context.

You should be careful when you're dealing with MzScheme's separate
phases.  If you want

  (defclass ColoredPoint (Point) color)

to generate a definition for `Point-x', then you need the information
that `Point' is a class that has an `x' slot at the *syntax* level.
There are ways to get some of this, but there are certain things that
you cannot do -- for example, in:

  (define ColoredPoint ((car (list Point))) color)

you will not know that there is an `x' field in the class because you
don't have a plain identifier that can be registered at the syntax
level.  (Of course one solution would be to restrict defclass to
accept only identifiers that were defined as classes.  This is done,
for example, in MzScheme's `define-struct' form (and that wouldn't
give you a `ColoredPoint-x' either).)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!