From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: EIEIO
Date: Fri, 14 Mar 2014 17:41:36 +0800 [thread overview]
Message-ID: <877g7xazhr.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 532268F2.60809@dancol.org
Daniel Colascione <dancol@dancol.org> 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!
next prev parent reply other threads:[~2014-03-14 9:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 3:04 About CEDET, Completion, and compilers Eric M. Ludlam
2014-03-13 13:40 ` Andreas Röhler
2014-03-13 14:04 ` João Távora
2014-03-13 14:21 ` Andreas Röhler
2014-03-14 0:36 ` Eric M. Ludlam
2014-03-14 2:26 ` EIEIO Daniel Colascione
2014-03-14 3:35 ` EIEIO Eric M. Ludlam
2014-03-14 6:42 ` EIEIO David Engster
2014-03-14 9:41 ` Eric Abrahamsen [this message]
2014-03-14 20:13 ` EIEIO Eric Schulte
2014-03-15 6:54 ` EIEIO Thien-Thi Nguyen
2014-03-16 1:06 ` ELPA Go integration Was: EIEIO Eric Schulte
2014-03-16 10:36 ` Thien-Thi Nguyen
2014-03-24 8:33 ` Thien-Thi Nguyen
2014-03-17 14:36 ` Stefan
2014-03-25 2:05 ` Stefan
2014-03-14 10:24 ` EIEIO João Távora
2014-03-14 6:47 ` About CEDET, Completion, and compilers Andreas Röhler
2014-03-23 14:57 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877g7xazhr.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.