[Ecls-list] ECL & Closer-mop

[Pascal Costanza]

Hi Juanja,

On 19 Nov 2012, at 10:36, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> 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?

No, this doesn't interfere with standard MOP usage. This is actually very similar to what I wanted to do within Closer to MOP. It's good if ECL itself already takes care of this, so what you do now is definitely better.

You could even go further, if you want to: The section "Restrictions on Portable Programs" discusses that methods on s-v-u-c and friends must not be defined anymore once instances of the respective metaclass have been created. This allows you to apply the optimization even for user-defined metaclasses  - but the price you pay is less flexibility to change definitions after the fact. (This could be further steered by optimization settings.)

> - It seems that slot-unbound is not correctly handled. Here is a test case:
> 
> Thanks for reporting this, Pascal. I just fixed it.

Thanks, I will test this.


Best,
Pascal

--
Pascal Costanza



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121124/2072a750/attachment.html>