all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: "Eric M. Ludlam" <eric@siege-engine.com>,
	"Andreas Röhler" <andreas.roehler@online.de>
Cc: emacs-devel@gnu.org
Subject: EIEIO
Date: Thu, 13 Mar 2014 19:26:58 -0700	[thread overview]
Message-ID: <532268F2.60809@dancol.org> (raw)
In-Reply-To: <53224F2B.3070600@siege-engine.com>

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

  reply	other threads:[~2014-03-14  2:26 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     ` Daniel Colascione [this message]
2014-03-14  3:35       ` EIEIO Eric M. Ludlam
2014-03-14  6:42       ` EIEIO David Engster
2014-03-14  9:41       ` EIEIO Eric Abrahamsen
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=532268F2.60809@dancol.org \
    --to=dancol@dancol.org \
    --cc=andreas.roehler@online.de \
    --cc=emacs-devel@gnu.org \
    --cc=eric@siege-engine.com \
    /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.