[plt-scheme] Re: Swindle CLOS ?

Eli Barzilay <eli at ...> writes:
 
> I don't see any reason to do this: conceptually, `x' is a field of
> Point, so a `ColoredPoint-x' doesn't make much sense to me.  But the
> `Point-x' thing is in any case a generic function -- which means that
> it does not "belong" to Point -- it just happens to have a method that
> is qualified for Points.  So, you can have it called `get-x' and then
> it's independent of any class name (there is an option that makes it
> use `x' for a name, it's just that it's a bad name in this case).
> (There is even a customization option that defines the accessor as a
> plain function instead of a generic -- basically one that is doing the
> actual accessing through (slot-ref foo 'x).)


Thanks for your reply Eli,

Don't confuse my wanting to emulate Meroonet with Swindle CLOS as an endorsement
of how Meroonet does things, its just the less I have to force the end user of
the module to change the code from the book the better job at porting I've done.
 Actually, before I started this project I had never used Swindle CLOS or CL's
CLOS for that matter.  I'm more used to the static view of a class you get from
using C++.  Swindle CLOS is actually an impressive piece of work, and I'm glad I
got a chance to learn some of it.

I saw the other options for accessor names, but they seemed worse by far than
the default, since you don't want name collisions between functions because you
haven't qualified the name with the class name.  I guess I'll just settle for
the default and provide instructions on how change the code to handle the
difference in naming conventions.  It too bad though, because this code is for
interpreters and compilers, and you'd like to start off with a baseline
identical to the code in the book to be sure you have it correct before you
start to fiddle with it.

Although, I must say, Swindle CLOS's use of keywords to identify arguments is
such a clearer way to insure you've set the variables the way you wanted, than
the way Meroonet does it, which is to have the programmer rely on their memory
of the ordering of slots, that I was already going to force this change on the
user, and it's one difference I could easily fix to make transparent.

The way I wished Queinnec had gone about the whole thing is as a real
implementor would have approached these issues.  So, instead of abstracting
continuations away with an OO system, my preference would have been that he
actually show the data structures that are being used to do these things in real
implementations.  There seems to me to be too many books that go that route and
virtually none that I know of devoted to spelling out the gritty details.  I
guess I'll have to get that from journal articles.

Anyway, thanks for the reply.  I just wanted to be sure I hadn't missed an
option somewhere that would have made it all magically work.

Thanks,

--kyle
kyle at bellsouth dot net
schemekey.blogspot.com