[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Anton Vodonosov]

22.01.2014, 23:54, "Robert P. Goldman" <rpgoldman at sift.info>:
> I think what Faré is pointing out is that one could build, for example,
> an introspection library by adding for example, PERFORM methods that
> would dispatch on OPERATION and that would catch *all* PERFORMS and
> write a log or something like that.
>
> If we no longer make OPERATION the root of the hierarchy then such
> introspection libraries will no longer work.

Ah, I see.

A formalist excuse for such cases may be "if you want to intercept
all PERFORMS, you should specialize your OPERATE method on T.
If you specialize on OPERATION, then you restrict the method to OPERATION" :)

If speak seriously, then I agree, the solution with OPERATION being
backward comp stub inherited from DOWNWARDS-OPERATION, SELFWARD-OPERATION, etc
is not absolute.

Another, very artificial example, is if someone examines class hierarchy programmatically,
to ensure asdf:operation is the root:

  (assert (equal (mapcar #'find-class '(asdf:operation standard-object t))
                 (class-precedence-list (find-class 'asdf:operation))))

There is some chance that clients will break when we introduce new
root BASE-OPERATION and leave OPERATION as a back comp stub.

The current ASDF3 solution where OPERATION becomes higher level root,
loosing part of its semantics also has some chance to break clients.

Then the solution with lower chance to break clients is better.

But I can't say how probable the "OPERATION is the root" solution
to break clients, as far as I now understand some of OPERATION-extending
systems may remain working, right? Would cffi-grovel and other use cases
provided by Fare work?

Sorry if I am making too much noise on the list, I become curious why it is so
problematic and it is an interesting design exercise. Also you could
have rejected the "new BASE-OPERATION root" solution early,
before the hard difficulties with other alternatives were found;
that happens some time. So we now reevaluated it.

Best regards,
- Anton