[asdf-devel] Tests completed

[Pascal Costanza]

On 17 Jan 2014, at 18:42, Robert P. Goldman <rpgoldman at sift.info> wrote:

> Pascal Costanza wrote:
>>>> If you want to implement checks on subclasses, it’s better to do this in initialize-instance / reinitialize-instance on metaclasses, but this requires that the subclasses also use those metaclasses, which may break other assumptions.
>>>> 
>>>> Sorry if this is a foolish question, but the class at issue here is
>>>> OPERATION, whose metaclass is STANDARD-CLASS.
>>>> 
>>>> So am I correct in thinking I would need something like
>>>> 
>>>> (defmethod INITIALIZE-INSTANCE :BEFORE ((class standard-class) &key
>>>> direct-superclasses)
>>>> (when (member (find-class 'asdf:operation) direct-superclasses)
>>>>   ...handle my troublesome case...)))
>>>> 
>>>> where the primary portability challenge would be to make sure I have the
>>>> right STANDARD-CLASS for the various implementations? [Hoping to
>>>> cargo-cult that out of Closer-MOP.]
>> 
>> You are not allowed to define a method for a pre-defined generic function in the MOP on a pre-defined metaclass like this. At least one specializer must be one of your own metaclasses. (See “restrictions on portable programs” in the “Concepts” section of the CLOS MOP specification. It’s _very_ important to stick to these restrictions.)
>> 
>> So your only chance is to define an operation-class metaclass, and make sure that operation is an instance of operation-class (or similar).
>> 
> 
> This is quite a crippling limitation, then.  Adding a metaclass would
> add another quite substantial amount of compatibility code to ASDF to
> permit us to use the MOP (even in a relatively limited way) on all of
> the supported implementations.
> 
> Can you think of any other way we might detect the creation of
> subclasses of OPERATION?

No, I don’t think there is any. There are good reasons for this limitation, including allowing CLOS implementations to be free of any restrictions when dealing with predefined metaclasses which enables good performance, and also ensuring that different metaclasses don’t step on each other’s toes.


Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.