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



--
Kenneth Tilton
Fort Lauderdale, FL
http://tiltontec.com
"In a class by itself." -Macworld