On 17 Jan 2014, at 19:06, Faré fahree@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