[Ecls-list] ECL & Closer-mop

[Pascal Costanza]

Hi,

OK, I can report a success: All my test cases run through now (almost, see below ;).

However, there are still some remaining bugs:

1) extract-specializer-names is not correct for eql specializers. Consider: (extract-specializer-names '((s (eql 's)))) => ((EQL S)). However, the result should be ((EQL 'S)), the quote should not be removed!

2) When an accessor method is initialized, it should be passed a :slot-definition argument to the slot it is supposed to access. This doesn't seem to happen.

3) When ADD-METHOD has to remove a method because of agreeing on specializers and qualifiers with the new method, it is specified to do so by invoking REMOVE-METHOD rather than by doing it by itself. However, this doesn't seem to be the case.

4) DEFMETHOD doesn't call MAKE-METHOD-LAMBDA to determine the method function body. [My guess is that this is not easy to change due to the deviation from the MOP specification in how method functions are called.]

5) (setf generic-function-name) is specified to invoke reinitialize-instance to do its job, rather than doing it by itself. However, this doesn't seem to be the case.

6) Many of the metaobject classes expose slots with names that are exported from some package or visible in CL-USER. This shouldn't be the case. (See "Restrictions on Implementations" in the MOP specification.)

Most of these should be very easy to fix (except for 4 probably). I could do most of them (except for 4 and 6) in Closer to MOP, but I guess it's better if you do them directly in ECL. Depending on how we agree, my internal development version of Closer to MOP for the next ECL is ready to be released. Please give me a sign when I should do that.

[I will skip support for the 12.7.1 because that is too much work and will be only of temporary value.]


Pascal


On 26 Nov 2012, at 23:35, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> On Mon, Nov 26, 2012 at 7:38 PM, Pascal Costanza <pc at p-cos.net> wrote:
> I don't think the HyperSpec allows for that interpretation. The entry for slot-value is specific that slot-unbound is called when a slot is unbound, and the entry for slot-unbound specifies that the default method signals an error of type unbound-slot. There are no exceptions specified for unsafe code. This is actually important, since the whole slot-unbound and slot-missing protocols can be used to define reasonable semantics, for example to define hash-table-based slots, and user code needs to be able to rely on the correct workings of user-defined extensions here even for unsafe code.
> 
> As I said, this optimization is taking place only for accessors over standard classes. In any case I have deactivated it because again we run into the eternal two problems that cannot be solved without dynamic recompilation:
> 
> 1) users might define methods with the same name over their own classes, even for the accessors that are defined in the CL package.
> 
> 2) as discussed in the pro mailing list, it is a nightmare to determine the actual class of an accessor argument -- the type declaration names only the parent class, but user's subclasses might not fullfil the same contracts as their parents.
> 
> It is really a nightmare trying to introduce any optimization with MOP around.
> 
> Juanjo
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com

--
Pascal Costanza



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