Re: EIEIO

[Eric Abrahamsen]

Daniel Colascione <address@hidden> writes:

> On 03/13/2014 05:36 PM, Eric M. Ludlam wrote:
>> The key thing that EIEIO lets me do is define interfaces that allows
>> modules to work together.  For example, there is a tag-table concept in
>> the semantic system for managing lists of symbols found in the source
>> code it parses.  The parser system all knows how to populate and
>> maintain a table.  There is also code that searches tables so you can
>> find a tag to jump to, for example.  By defining the core interface as a
>> table class with EIEIO, I can also create other classes that manages tag
>> tables from GNU Global, and just stick it in a list of other tables to
>> search.  The code searching tables doesn't have to know  about GNU
>> Global.  The Global person doesn't have to know about jumping to tags.
>> And no-one has to write some weird bit of code that reaches into a plist
>> to get a function symbol to call.  I was able to move the Java
>> completion in CEDET from in-file only to surprisingly robust for Android
>> in an afternoon just by writing a database that parses a few.jar files.
>>  Nifty.
>
> Thanks for putting work into CEDET. I expect to be writing some Java in
> the near future, so I'll probably be taking a much closer look at it soon.
>
> I agree that polymorphism is useful when implementing and extending a
> system like CEDET. Emacs has traditionally used dispatch functions in
> cases like this, though: look at file-name-handler-alist. Consequently,
> EIEIO feels a bit foreign. What motivated the choice of EIEIO over
> dispatch functions or defstructs with function slots?
>
> A while ago, I considered using EIEIO for one of my projects; I decided
> to use plain defstructs instead. I didn't like how EIEIO required each
> object to have a name (requiring that EIEIO allocate a new string for
> each object instance), and I had very simple interface requirements, and
> found calling funcall on a struct slot more straightforward than a
> generic function. I still don't know how method dispatch actually works
> or what the performance characteristics of the various combination
> methods are. It's also not clear what happens on method redefinition,
> package unloading, and so on.
>
> CLOS is a comprehensive OO system, but I'm not sure we're dealing with a
> problem that actually requires its power.

FWIW, while debugging gnus, I have wished with great fervor that it was
written in an OO style. Half of the functions look like "(funcall (assoc
'current-context enormous-context-list)..." and it's murder trying to
figure out what context we're in. It seems like gnus is a perfect case
study for the benefits of object-oriented programming: encapsulation and
polymorphism. They should teach it in school!