"Pascal J. Bourguignon" <pjb@...> writes:
> Tomasz Gajewski <tomga@...> writes:
>> To better understand api of ede I wanted to check api for classes. As
>> the documentation seems to not be fully accurate (details later) I
>> wanted to check how cogre works for those classes. At first it seemed
>> to be working fully as expected (it is really awesome) but there was
>> no methods on the diagram. I've checked in the cogre code and it
>> seems that there is support for externally defined methods (just like
>> in eieio) but it doesn't work. I failed to find out why. I don't know
>> enough to debug this.
>> I wanted to describe it in more details but later I've found out that
>> sample diagram on http://cedet.sourceforge.net/uml.shtml is based on
>> eieio classes and doesn't have methods either.
>> Is it supposed to work?
> …as it does, yes.
> You see, the point is that eieio is a CLOS-like object system, and in
> CLOS, classes don't have methods. Methods are not attached to classes
> in CLOS, but to generic functions. It is generic functions that have
> methods. Generic functions will dispatch to one method or another,
> depending on the class of their arguments (well, ok, in the case of
> eieio, it's only the class of one of their arguments, no multiple
> dispatch here).
> So the structure of CLOS (eieio), just does not match the structure
> imposed by UML.
Thanks for this explanation. I don't know CLOS. I'm just trying to get
used to elisp by experimenting with cedet. As I've seen somewhere in
documentation that eieio matches functions only using first class
argument it seems just like methods on classes. In addition to that I've
seen somewhere comment (I think somewhere in cogre) about externally
defined methods "like in elisp" that led me thinking in OO therms. Eric
made this to work anyway (even if it is not in spirit of uml) and it
helps to analyse the structure of classes especially given the fact that
they are implemented in different places.
> That said, conceptually, and the more when eieio doesn't allow for
> multiple dispatch, one could indeed document generic function methods
> in relation with the classes they dispatch on. The only difficulty
> here is that there's no easy way to find all the methods of all the
> generic functions that dispatch on a given class. (I mean, no O(1) way
> to do it, you will have to scan all the symbols, find all the
> functions, filter out non generic functions, for each function, find
> all the methods, filter out the methods that don't dispatch on the
> class (well, ok, you're lucky, eieio allows dispatch only on the first
> argument, so there's only one method per generic function per class)).
I think you have not taken into account information that lookup is
performed on semantic database not on the list of registered elisp
functions and I think that we can restrict the list to those functions
that are defined by macro 'defmethod' without loosing much accuracy.
As about the cost of this operation I cannot say anything about that for
sure because I don't know anything about semanticdb implementation
yet. I can only see that it can be no worse than class information
retrieval. O(log(n)) for class definition lookup (on number of classes)
and the same for such methods lookup (on number of methods).