[Ecls-list] Change

Juan Jose Garcia-Ripoll jjgarcia at users.sourceforge.net
Mon Apr 28 16:06:45 UTC 2008

Tag: (CVS 2008-04-28 17:22)

I have implemented accessor methods. I had this in the drawer and the
fact  that some library uses them motivated me to commit the change.

For those who do not know the Metaobject Protocol, accessor methods
are objects that control the :reader and :writer methods created for
accessing slots in a CLOS object. The AMOP specifies a protocol by
which these methods can be provided by the user, who can then
"interfere" with the functions that are generated and change the
behavior of these readers/writers. This is useful, AFAIK, for
implementing persitence.

The only problem with this is that accessors can no longer know the
position of the slots in the class: this has to be queried on each
call to the accessor function. My reasoning is the following: The user
can use standard accessor classes to alter the creation of slot
accessors. However, the AMOP specifies that this only happens for the
direct slots in a class. So, in
   (defclass foo () ((a :reader foo-a)))
   (defclass faa (foo) ((b :reader foo-b)))
this implies that only _two_ accessors are created: FOO-A and FOO-B.
In principle the position of slot A in class FAA need not be the same
as in FOO, therefore the methods that we create have to be independent
of this detail and rely only on SLOT-VALUE.

Formerly we would create one method per class slot. When a class
inherited slots from another class, we would also create specialized
version of those methods. Hence in the previous example we would see
two implementations of FOO-A and one for FOO-B. Each implementation
would have the position of the slot memoized.

The problem now appears because if we left this optimization in the
CLOS library, we could potentially mix classes that bear optimized
slots and those which do not, having a mess which is difficult to keep
track of.

So, I opted for the simplest solution which is to use the standard
method. Incidentally it also conses less, as it creates a single
function per direct slot.


Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)

More information about the ecl-devel mailing list