Accessor names for flavor instance variables

["William M. York" <York%chuck-jones.ila-west.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Fri, 2 Jun 89 14:17:44 EDT
    From: steveo@Think.COM (Steve Anthony)

	   Date: Fri, 2 Jun 89 07:24:09 mdt
	   From: intvax!drstrip@unmvax.cs.unm.edu

	   I would like the accessor functions for the instance
	   variables of g to be g-a, g-b, ... Unfortunately, it seems
	   that the accessor function name is based on the accessor
	   name of the mixin.

    Another thing that frustrates me about this is that if you use the old
    style invocation; :settable, :gettable :initable,  then you could do a
    (send <instance of g> :a).  The new invocation requires you to keep track
    of the flavor an instance variable is defined for.

That isn't exactly true.  The new scheme requires you to think a little
bit about the protocols you are defining and which classes of object
support which protocols, but you should have been doing this thinking
all along.  If for "a" we take a commonly-occuring instance variable,
such as "name", you can just define an "accessor" named "NAME" that will
work on all objects for which it is meaningful to return a name.  Thus
you define the F mixin to support NAME and the G class inherits the name
operation, all without the user or programmer needing to know which
mixin is responsible for supporting which operations.

As a thought experiment your complaint should be satisfied just by using
the :CONC-NAME NIL option to defflavor.  This will give you accessor
functions that have the same names as the instance variables they
reference, and you can reference any IV without any need to know which
component flavor defines it.  Of course at this point you might complain
about cluttering up the function name namespace and generating
collisions when you mix flavors together (or mix flavor IV accessors
with other functions), but you certainly had to be careful about
collisions in the message namespace under the old scheme.  If you
weren't, it was just a matter of time until you had a disaster.
After all, if you haven't defined your protocols, you can't really just
assume that some object that happens to support a message named :NAME
will really return a string naming the object.