22.01.2014, 23:54, "Robert P. Goldman" rpgoldman@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