Re: [eieio] :before and :after methods not called

drkm <[email protected]> Mon, 04 Apr 2005 10:33:14 +0200
Newsgroups gmane.emacs.cedet,gmane.emacs.eieio
Organization None
Message-ID <[email protected]>
drkm <[email protected]> writes:

> "Eric M. Ludlam" <[email protected]> writes:

>>   I checked in changes to eieio to do this mechanism for method calls.
>> I submitted a new test file for methodinvocation tests.

>   Good news.

  I just take a look at this new file.  In the second test, you
include (F :PRIMARY B-base2) in the result, if I understand.  IMHO, it
must not be there.

  The standard method combination take the first applicable primary
method, (F :PRIMARY B), because B is the most derived class.

  This method call call-next-method.  So (F :PRIMARY B-base1) is
called.  B-base1 take precedence over B-base2, because it stands more
on the left in the superclass list from the definition of the class B.

  Because this method doesn't call call-next-method, (F :PRIMARY
B-base2) is not called at all.

  BTW, in the first test, I think it's better to not define
(F :PRIMARY AAA).  So the result will have to be:

    (F :BEFORE AAA)
    (F :BEFORE AA)
    (F :BEFORE A)
    (F :PRIMARY AA)
    (F :AFTER A)
    (F :AFTER AA)
    (F :AFTER AAA)

  I guess starting at different "levels" could be better for testing.
Maybe introduce a "hole" in the :BEFORE and :AFTER lists could be of
some benefit, too.  Like something like that:

    (F :BEFORE AAA)
    (F :BEFORE A)
    (F :PRIMARY AA)
    (F :AFTER A)
    (F :AFTER AAA)

  To be sure the implementation don't just walk in the class
inheritence graph until some nil is encountered (or something like
that).

  Thanks,

--drkm



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click