You are puzzliing over undefined behavior, meaning what you have discovered:is that implementations are free to go as crazy as, well, canines in a dog park. This can be excitingly crazy, because the CL standardizers were too exhausted to include the MOP in the standard. (They made nice excuses about not wanting to inhibit implementers, but dollars to donuts they just ran up the white flag in the face of the idea of standardizing something as vast in itself as a complete HLL).
What were actually trying to build?
-kt
On Fri, Aug 1, 2014 at 10:00 PM, Pascal J. Bourguignon < pjb@informatimago.com> wrote:
Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com writes:
So my question is: Which one is right?
I'd note that this is a major problem of how OO libraries or frameworks are defined. They very rarely specify or give any guarantee of when or whom will send a given message to a given object.
This makes indeed difficult to subclass and override methods in a sturdy way.
This is probably a reason why OO programmers nowadays tend to distance themselves from inheritance (using so called "flat" hierarchies), and like "final" methods a lot, which basically denies OO itself.
Otherwise, for your question, you didn't mention any metaclass. I'm not sure about it, but I would expect such methods from AMOP to be used consistently only when you define your own metaclasses.
-- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro