[asdf-devel] Tests completed
pc at p-cos.net
Sat Jan 18 12:57:46 UTC 2014
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…)
More information about the asdf-devel