[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EIEIO
From: |
Eric Abrahamsen |
Subject: |
Re: EIEIO |
Date: |
Fri, 14 Mar 2014 17:41:36 +0800 |
User-agent: |
Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) |
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!
- About CEDET, Completion, and compilers, Eric M. Ludlam, 2014/03/12
- Re: About CEDET, Completion, and compilers, Andreas Röhler, 2014/03/13
- Re: About CEDET, Completion, and compilers, João Távora, 2014/03/13
- Re: About CEDET, Completion, and compilers, Eric M. Ludlam, 2014/03/13
- EIEIO, Daniel Colascione, 2014/03/13
- Re: EIEIO, Eric M. Ludlam, 2014/03/13
- Re: EIEIO, David Engster, 2014/03/14
- Re: EIEIO,
Eric Abrahamsen <=
- Re: EIEIO, Eric Schulte, 2014/03/14
- Re: EIEIO, Thien-Thi Nguyen, 2014/03/15
- ELPA Go integration Was: EIEIO, Eric Schulte, 2014/03/15
- Re: ELPA Go integration Was: EIEIO, Thien-Thi Nguyen, 2014/03/16
- Re: ELPA Go integration Was: EIEIO, Thien-Thi Nguyen, 2014/03/24
- Re: ELPA Go integration Was: EIEIO, Stefan, 2014/03/17
- Re: ELPA Go integration Was: EIEIO, Stefan, 2014/03/24
- Re: EIEIO, João Távora, 2014/03/14
- Re: About CEDET, Completion, and compilers, Andreas Röhler, 2014/03/14
Re: About CEDET, Completion, and compilers, Richard Stallman, 2014/03/23