[Ecls-list] ECL & Closer-mop

Juan Jose Garcia-Ripoll juanjose.garciaripoll at gmail.com
Mon Nov 19 09:36:26 UTC 2012


On Sun, Nov 18, 2012 at 11:38 PM, Pascal Costanza <pc at p-cos.net> wrote:

> I'm back in the land of the living… ;)
>

Thanks for getting back to this!


> - Previously, ECL had a way of specifying :optimize-slot-access for
> classes to state whether slot access should go through the CLOS MOP slot
> access functions or should be optimized. Judging from the source code for
> ECL, this is still supposed to be supported, but it seems that the defclass
> macro, or some level in between before shared-initialize cannot handle this
> option anymore.
>

Ok, now the interface has changed a bit. Please allow me to explain how it
works

* At the class level, when slot accessors are generated, they are _always_
optimized if the class is an instance of standard-class or
funcallable-standard-class. Otherwise slot-value is used. The reason for
this is that according to MOP, one is not allowed to define methods on
slot-value for those metaclasses and thus the optimization should be safe.

* At the generic function level, when a generic function contains only
standard-reader/writer-methods and no methods has a before, after, around,
etc, and those methods have been optimized then ECL internally replaces the
dispatch function with an optimized one for slot accessors.

If you found that this interferes with standard MOP practices, could you
please give a hint about where one and how?


> - It seems that slot-unbound is not correctly handled. Here is a test case:
>

Will look into that.

Thanks again,

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121119/1977faca/attachment.html>


More information about the ecl-devel mailing list