[plt-scheme] Re: Swindle CLOS ?

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

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.

Well thats at least one plausible argument for the way Meroonet does 
things.  If I were hand coding an application
I could always create the accessors at top-level for ColoredPoint that 
were needed for an interface.   This is
really only an issue because I can't figure a way to evaluate the 
defmethod expressions to create the accessors
programatically without ending up with the class being defined at 
top-level and the methods being defined as
locals.

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.

Thanks again for your reply,

--kyle

Kyle Smith
airfoil at bellsouth dot net
schemekeys.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070310/c97c02a7/attachment.html>