CEDET

I'm not Eric, but I'll try to answer anyway. ;-)

Pierre Lorenzon <devel@...> writes:
> it was not clear for me how call-next-method should act. In my mind,
> it must be something like super in java or c++ or parent in php.

No, CLOS is fundamentally different from OO in languages like Java, C++
or PHP. 'call-next-method' calls the next most specific method, and that
depends on how the method was invoked.

> It means in particular that if C' is another class inheriting
> from B, if we call method `method' in C',
> eieio-generic-call-next-method-list can be differently
> initialized as it would be if calling from C. As a consequence
> the call-next-method call in method `method' in B might have a
> different effect. Is it really desired ?

I think so. But I'm not a CLOS expert, so maybe I'm wrong.

When I have questions like this, I usually search
comp.lang.lisp. Regarding your case, the following thread should be
interesting, especially this post:

http://tinyurl.com/y8sx5r7

Regards,
David

From: David Engster <deng@...>
Subject: Re: [CEDET-devel] Fw: eieio call-next-method ?
Date: Thu, 19 Nov 2009 20:16:06 +0100

> I'm not Eric, but I'll try to answer anyway. ;-)
> 
> Pierre Lorenzon <devel@...> writes:
>> it was not clear for me how call-next-method should act. In my mind,
>> it must be something like super in java or c++ or parent in php.
> 
> No, CLOS is fundamentally different from OO in languages like Java, C++
> or PHP. 'call-next-method' calls the next most specific method, and that
> depends on how the method was invoked.

  That's the point ! OK if it is language specs nothing to
  say. Except that :

  1. At this point, eieio documentation is not really precise 


>>>  -- INFO 

`call-next-method'
     Inside a method, calls the next available method up the
     inheritance tree for the given object.  This is different than

>>>  -- End INFO 

     inheritance tree sounds to me like something static not
     influenced by the way the method is called.

     2. A super or parent operator could easily implemented in
     eieio as I suggested and I personnally think that it could
     be useful.

     Pierre

Pierre Lorenzon <devel@...> writes:
> From: David Engster <deng@...>
>> I'm not Eric, but I'll try to answer anyway. ;-)
>> 
>> Pierre Lorenzon <devel@...> writes:
>>> it was not clear for me how call-next-method should act. In my mind,
>>> it must be something like super in java or c++ or parent in php.
>> 
>> No, CLOS is fundamentally different from OO in languages like Java, C++
>> or PHP. 'call-next-method' calls the next most specific method, and that
>> depends on how the method was invoked.

>   1. At this point, eieio documentation is not really precise 
>
>>>>  -- INFO 
>
> `call-next-method'
>      Inside a method, calls the next available method up the
>      inheritance tree for the given object.  This is different than
>
>>>>  -- End INFO 

>      inheritance tree sounds to me like something static not
>      influenced by the way the method is called.

I agree, this should be changed. While you can mimic the hierarchical OO
from C++/Java with EIEIO, it just doesn't fit and leads to confusion.

>      2. A super or parent operator could easily implemented in
>      eieio as I suggested and I personnally think that it could
>      be useful.

In CLOS, methods do not "belong" to classes. While for simple examples,
something like 'A.method()' and '(method A)' look awfully alike, there
is a fundamental difference between those two, and it becomes very
obvious when you take a look at how multiple inheritance works in
CLOS. It's really just a logical extension of method specialization
('(method A B)'), and this is only possible because you don't have to
care to which class a method "belongs"; methods are specialized,
instead.

Regards,
David

Pierre Lorenzon <devel@...> writes:
> Next question is : when can `call-next-method' be safely used ?
> Imagine someone providing a packages of classes fitting certain
> specifications. And imagine you want simply to develop classes
> inheriting from classes of the package. If call-next-method is
> used in the derived classes there is something unstable.

While I'm really no CLOS expert and this is getting off-topic, I'll
still try to answer this, but please take the following with a grain of
salt. comp.lang.lisp would surely be the better place to discuss this
(it's not a very newbie-friendly place, though. It's usually expected
that one has done some reading... ;-) ).

You first have to understand that at the heart of CLOS are *not*
classes. This is the fundamental difference to C++/Java, where you first
define classes, and then you define methods that *belong* to those
classes. One of the central ideas there is that classes define a fixed
interface, and if you inherit from such a class, you're automatically
forced to stick to that.

But at the heart of CLOS are not classes, but *generic methods*, which
is less surprising if you remember that LISP is still a functional
language, so it makes sense that it should be functions which are at the
center of its OO system. This leads to a different kind of
object-orientation, vastly different from C++/Java. While you can mimic
the typical OO known from those languages in CLOS, it really doesn't do
it justice, and I think that is what leads to your confusion. As I said
before, CLOS really begins to shine when you start to use multiple
inheritance, which is usually something you try to avoid in C++, because
it brings a whole bunch of new pitfalls.

'call-next-method' is indeed a weird beast. You usually use it in
':around' methods to invoke the remaining implementations. If you do not
do this, the ':around' method will completely "hijack" the
implementation (but there are cases where this might make sense). Of
course, you must be sure that there actually are next methods to call. I
understand your reasoning that if you use an existing library, the
maintainer could break your existing code any time, but that's the case
with C++/Java, too: if the maintainer decides to change the interface,
your existing code will break.

If you would like to just execute something before or after the primary
method, you just use :before and :after methods (you cannot use
call-next-method in before/after methods). For example, an :after method
of initialize-instance can be seen as a 'constructor'.

I'm guessing what you're after is to use call-next-method in primary
methods? While I'm pretty sure this is legal, it should be avoided; it
makes the code complicated and difficult to debug. If you think you have
to use call-next-method in primary methods, this usually means you
should refactor.

Regards,
David

Hi,

Next question is : when can `call-next-method' be safely used ?
Imagine someone providing a packages of classes fitting certain
specifications. And imagine you want simply to develop classes
inheriting from classes of the package. If call-next-method is
used in the derived classes there is something unstable. If the
one who provided the classes package changes the implementation
still fitting the specifications, everything can be broken if,
for instance call-next-method are used in the new
implementation. Recursive uses of call-next-method can appear
and as I pointed it it might be brake everything. You can for
instance get a no next method error, even if the class as a
parent class. It is absolutely not comfortable ! I cannot
believe that details of the implementation might be part of the
specifications. 

Hence, my answer to the above question "when can
call-next-method be safely used" would be NEVER it is too
DANGEROUS !

Anyway, the point might be that I did not understood CLOS
philosophy and have to think again how things I wnat to
implement might be implemented in CLOS !

Regards

Pierre


From: David
Engster <deng@...> Subject: Re: [CEDET-devel] Fw:
eieio call-next-method ?  Date: Thu, 19 Nov 2009 22:38:14 +0100

> Pierre Lorenzon <devel@...> writes:
>> From: David Engster <deng@...>
>>> I'm not Eric, but I'll try to answer anyway. ;-)
>>> 
>>> Pierre Lorenzon <devel@...> writes:
>>>> it was not clear for me how call-next-method should act. In my mind,
>>>> it must be something like super in java or c++ or parent in php.
>>> 
>>> No, CLOS is fundamentally different from OO in languages like Java, C++
>>> or PHP. 'call-next-method' calls the next most specific method, and that
>>> depends on how the method was invoked.
> 
>>   1. At this point, eieio documentation is not really precise 
>>
>>>>>  -- INFO 
>>
>> `call-next-method'
>>      Inside a method, calls the next available method up the
>>      inheritance tree for the given object.  This is different than
>>
>>>>>  -- End INFO 
> 
>>      inheritance tree sounds to me like something static not
>>      influenced by the way the method is called.
> 
> I agree, this should be changed. While you can mimic the hierarchical OO
> from C++/Java with EIEIO, it just doesn't fit and leads to confusion.
> 
>>      2. A super or parent operator could easily implemented in
>>      eieio as I suggested and I personnally think that it could
>>      be useful.
> 
> In CLOS, methods do not "belong" to classes. While for simple examples,
> something like 'A.method()' and '(method A)' look awfully alike, there
> is a fundamental difference between those two, and it becomes very
> obvious when you take a look at how multiple inheritance works in
> CLOS. It's really just a logical extension of method specialization
> ('(method A B)'), and this is only possible because you don't have to
> care to which class a method "belongs"; methods are specialized,
> instead.
> 
> Regards,
> David

David Engster wrote:
> Pierre Lorenzon <devel@...> writes:
>> Next question is : when can `call-next-method' be safely used ?
>> Imagine someone providing a packages of classes fitting certain
>> specifications. And imagine you want simply to develop classes
>> inheriting from classes of the package. If call-next-method is
>> used in the derived classes there is something unstable.
[...]
> But at the heart of CLOS are not classes, but *generic methods*, which
> is less surprising if you remember that LISP is still a functional
> language, so it makes sense that it should be functions which are at the
> center of its OO system. This leads to a different kind of
> object-orientation, vastly different from C++/Java. While you can mimic
> the typical OO known from those languages in CLOS, it really doesn't do
> it justice, and I think that is what leads to your confusion. As I said
> before, CLOS really begins to shine when you start to use multiple
> inheritance, which is usually something you try to avoid in C++, because
> it brings a whole bunch of new pitfalls.

It probably doesn't help that EIEIO does not implement generic method 
dispatching properly.  In EIEIO, method specialization only can occur on 
the first argument, and that first argument MUST be an EIEIO defined 
class.  In CLOS, all arguments can be specialized to any lisp supported 
type.

A side effect is that it makes method dispatch in EIEIO look a lot like 
C++ with OBJ.method() looking like method(OBJ).  In CLOS, however, you 
can have method(OBJ1,OBJ2) being different from method(OBJ1,INT).

This restriction is merely to simplify my task when I implemented it, 
and because I didn't really understand what was going on in CLOS, or how 
to implement real method specialization.

There are also many places in CEDET that use `call-next-method' in a way 
that is reminiscent of super->method().  :BEFORE and :AFTER methods came 
late in EIEIO's development.

Eric

If you are worried about that, you can either use condition-case to 
catch the 'no-next-method signal, or your subclass can implement the 
no-next-method method (which would not call call-next-method), and you 
would be robust to any such change.

Though, I don't really understand the problem.  Changing libraries 
breaks things all the time regardless of language.  Can you provide a 
concrete example of something that is unique to call-next-method?

I also think David is probably more qualified to talk about CLOS 
philosophy than myself.  I use EIEIO is a very C++ sort of way.

Eric

Pierre Lorenzon wrote:
> Hi,
> 
> Next question is : when can `call-next-method' be safely used ?
> Imagine someone providing a packages of classes fitting certain
> specifications. And imagine you want simply to develop classes
> inheriting from classes of the package. If call-next-method is
> used in the derived classes there is something unstable. If the
> one who provided the classes package changes the implementation
> still fitting the specifications, everything can be broken if,
> for instance call-next-method are used in the new
> implementation. Recursive uses of call-next-method can appear
> and as I pointed it it might be brake everything. You can for
> instance get a no next method error, even if the class as a
> parent class. It is absolutely not comfortable ! I cannot
> believe that details of the implementation might be part of the
> specifications. 
> 
> Hence, my answer to the above question "when can
> call-next-method be safely used" would be NEVER it is too
> DANGEROUS !
> 
> Anyway, the point might be that I did not understood CLOS
> philosophy and have to think again how things I wnat to
> implement might be implemented in CLOS !
> 
> Regards
> 
> Pierre
> 
> 
> From: David
> Engster <deng@...> Subject: Re: [CEDET-devel] Fw:
> eieio call-next-method ?  Date: Thu, 19 Nov 2009 22:38:14 +0100
> 
>> Pierre Lorenzon <devel@...> writes:
>>> From: David Engster <deng@...>
>>>> I'm not Eric, but I'll try to answer anyway. ;-)
>>>>
>>>> Pierre Lorenzon <devel@...> writes:
>>>>> it was not clear for me how call-next-method should act. In my mind,
>>>>> it must be something like super in java or c++ or parent in php.
>>>> No, CLOS is fundamentally different from OO in languages like Java, C++
>>>> or PHP. 'call-next-method' calls the next most specific method, and that
>>>> depends on how the method was invoked.
>>>   1. At this point, eieio documentation is not really precise 
>>>
>>>>>>  -- INFO 
>>> `call-next-method'
>>>      Inside a method, calls the next available method up the
>>>      inheritance tree for the given object.  This is different than
>>>
>>>>>>  -- End INFO 
>>>      inheritance tree sounds to me like something static not
>>>      influenced by the way the method is called.
>> I agree, this should be changed. While you can mimic the hierarchical OO
>> from C++/Java with EIEIO, it just doesn't fit and leads to confusion.
>>
>>>      2. A super or parent operator could easily implemented in
>>>      eieio as I suggested and I personnally think that it could
>>>      be useful.
>> In CLOS, methods do not "belong" to classes. While for simple examples,
>> something like 'A.method()' and '(method A)' look awfully alike, there
>> is a fundamental difference between those two, and it becomes very
>> obvious when you take a look at how multiple inheritance works in
>> CLOS. It's really just a logical extension of method specialization
>> ('(method A B)'), and this is only possible because you don't have to
>> care to which class a method "belongs"; methods are specialized,
>> instead.
>>
>> Regards,
>> David
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

Eric M. Ludlam <eric@...> writes:
> This restriction is merely to simplify my task when I implemented it, 
> and because I didn't really understand what was going on in CLOS, or how 
> to implement real method specialization.
>
> There are also many places in CEDET that use `call-next-method' in a way 
> that is reminiscent of super->method().  :BEFORE and :AFTER methods came 
> late in EIEIO's development.

I also forgot that EIEIO does not support :around methods, so I guess
that you have to use call-next-method in primary methods.

>From your other post:
> Though, I don't really understand the problem.  Changing libraries
> breaks things all the time regardless of language.  Can you provide a
> concrete example of something that is unique to call-next-method?

He wants call-next-method to behave like super. Let me try to give an
example, which I think capture's what he's worried about (Pierre, please
correct me if I'm wrong):

---
(defclass A () () )
(defmethod method ((arg A) &rest args)
	   (message "A: method")
	   nil)

(defclass B (A) () )
(defmethod method ((arg B) &rest args)
  	   (message "B: method")
	   (call-next-method))

(setq objectB (make-instance 'B))
;; Lets call the method!
(method B)
---

So far, so easy. This will output

B: method
A: method

So in this case, call-next-method will behave like 'super'.

Let's add another class:

---
(defclass C (B) () )
(defmethod method ((arg C) (arg2 C) &rest args)
	   (message "C: method")
	   (call-next-method))

(setq objectC (make-instance 'C))
(method objectC objectC)
---

This will output

C: method
B: method
A: method

The 'call-next-method' in 'B' still behaves like 'super'.

But now, let's specialize 'method' some more:

---
(defmethod method ((arg A) arg2  &rest args)
	   (message "foo")
	   nil)
;; same call as above!
(method objectC objectC)
---

This will output

C: method
B: method
foo

Suddenly, call-next-method in class B will *not* behave like 'super'
anymore.

Regards,
David

David Engster wrote:
> Eric M. Ludlam <eric@...> writes:

>>From your other post:
>> Though, I don't really understand the problem.  Changing libraries
>> breaks things all the time regardless of language.  Can you provide a
>> concrete example of something that is unique to call-next-method?
> 
> He wants call-next-method to behave like super. Let me try to give an
> example, which I think capture's what he's worried about (Pierre, please
> correct me if I'm wrong):
> 
> ---
> (defclass A () () )
> (defmethod method ((arg A) &rest args)
> 	   (message "A: method")
> 	   nil)
> 
> (defclass B (A) () )
> (defmethod method ((arg B) &rest args)
>   	   (message "B: method")
> 	   (call-next-method))
> 
> (setq objectB (make-instance 'B))
> ;; Lets call the method!
> (method B)
> ---
> 
> So far, so easy. This will output
> 
> B: method
> A: method
> 
> So in this case, call-next-method will behave like 'super'.
> 
> Let's add another class:
> 
> ---
> (defclass C (B) () )
> (defmethod method ((arg C) (arg2 C) &rest args)
> 	   (message "C: method")
> 	   (call-next-method))
> 
> (setq objectC (make-instance 'C))
> (method objectC objectC)
> ---
> 
> This will output
> 
> C: method
> B: method
> A: method
> 
> The 'call-next-method' in 'B' still behaves like 'super'.
> 
> But now, let's specialize 'method' some more:
> 
> ---
> (defmethod method ((arg A) arg2  &rest args)
> 	   (message "foo")
> 	   nil)
> ;; same call as above!
> (method objectC objectC)
> ---
> 
> This will output
> 
> C: method
> B: method
> foo
> 
> Suddenly, call-next-method in class B will *not* behave like 'super'
> anymore.

So... it's more that you can change method((arg A)) from outside a 
library?  If so, that explains my confusion, since that's just a Lisp 
thing and not related to classes or methods.  I have used this technique 
many times against shipping Emacs code to make it do what I want.  I 
grand feature I enjoy using. :)

Eric

Hi All,

I identified the problem with call-next-method. Maybe not a
problem but only the way the inheritance tree is constructed. I
do not know yet how to work around this problem but here are
the facts :

The last command in the file cnm.el produces a unbound slot
error. Indeed constructor of class A is not executed, or at
least after that of that of eieio-default-superclass as shown
in this piece of my *Messages* buffer :

>>>  -- *Messages* 

Constructing C
Next methods ((B1 . B1) (eieio-default-superclass . eieio-default-superclass) (A . A))
Constructing B1
Next methods ((eieio-default-superclass . eieio-default-superclass) (A . A))

>>>  -- End *Messages* 

The problem is that C inherit from B1 and B2 and therefor A
seems to be more far away from C thant
eieio-default-superclass. 

The point that leads me to these mistakes is that if thing are
done from B1 it works well but from C no longer. Surely from
any child of C it's worst !

Well anyway if the inheritance tree is calculated in eieio in a
CLOS compatible way ! Once more nothing to say except that I
SHOULD adapt my code to the language specifications. Anyway in
my opinion it might generate very unstable situations. I didn't
discover the problem in C itself but in a child of C. Well,
suppose that you first set C to be only a child of B1. The
child D of C will work perfectly since constructor of A will be
executed in any situation. Decide then to add B2 inheritance to
C, everything will be broken ! Good or not ? I don't know but
anyway such unstability won't appear in java c++ php or
whatever similar. Simply say that otehr unstabilities might
occur ! and once more I will have to answer that I have
definitely to learn this CLOS !!!

Finally perhaps to "much ado about nothing" !

Regards

Pierre

Hi Again,

OK I think I found how to work around the problem. Its
sufficient to specialize actually constructor for class B2 in
my example. In fact for every "side class". Then the
inheritance tree has a more suitable aspect and it
works. Anyway I maybe would not have problem with other methods
thant the constructor. Indeed constructor exists implicitely
for each class even if it is not explicitely specialized. But
if not explicitely specialized it does not appear in the method
hierarchy. Should it ? Specialists will certainly answer that
not and that there are good reasons for that. So I'll
specialize constructor explicitely in my classes !

Regards

Pierre

Hi Pierre

Thanks for the news.  I was about to finally dig into your previous 
email to understand what the issue is, and I guess now I don't have to.

If there is a CLOS incompatibility with the method invocation order, 
then certainly it is still worth fixing.  What I'm not sure of is if 
that is the case, as I'm not a CLOS expert.

In either case, I'm glad you found a way to get your project working.
Eric


Pierre Lorenzon wrote:
> Hi Again,
> 
> OK I think I found how to work around the problem. Its
> sufficient to specialize actually constructor for class B2 in
> my example. In fact for every "side class". Then the
> inheritance tree has a more suitable aspect and it
> works. Anyway I maybe would not have problem with other methods
> thant the constructor. Indeed constructor exists implicitely
> for each class even if it is not explicitely specialized. But
> if not explicitely specialized it does not appear in the method
> hierarchy. Should it ? Specialists will certainly answer that
> not and that there are good reasons for that. So I'll
> specialize constructor explicitely in my classes !
> 
> Regards
> 
> Pierre
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>