[asdf-devel] Tests completed

[Pascal Costanza]

On 17 Jan 2014, at 19:06, Faré <fahree at gmail.com> wrote:

>>> 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?
>> 
> It would be nice if ASDF could do without pulling in closer-mop or
> substantial parts thereof.

I agree, especially since there are still CL implementations that closer-mop doesn’t cover.

> Adding a metaclass might also in and of itself be an incompatibility,
> which might require all clients to be updated to use the metaclass, in
> addition to requiring a punt during hot upgrade (i.e. dropping
> existing state on the ground). I'm not sure it is worth the cost at
> this point.

You can define a metaclass in such a way that subclasses of standard-class are still compatible with it.

> As suggested previously, a :before or :after method on make-instance
> for operation objects or such should be enough for this particular
> case, although this defers the warning until the operation is used,
> rather than when it is defined.

I agree that this is the best solution.

> The big problem, however, in this case, is still how do you
> distinguish between a "good" class that shouldn't trigger a warning,
> and a "bad" class that should.

By deprecating the use of operation as a superclass, and providing a new ‘new-operation class (or some such) that user code has to use instead. (new-operation could be a subclass of operation…)


Pascal

--
Pascal Costanza