<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body alink="#ee0000" bgcolor="#ffffff" link="#0000ee" text="#ffffff" vlink="#551a8b"> Eli Barzilay wrote: <blockquote cite="mid17906.4456.675698.969095@kinyarwanda.ccs.neu.edu" type="cite"> <pre wrap="">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).)</pre> </blockquote> 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 </body> </html>