On Sun, Nov 18, 2012 at 11:38 PM, Pascal Costanza <email@example.com> 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:Thanks for reporting this, Pascal. I just fixed it.