From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: EIEIO Date: Fri, 14 Mar 2014 17:41:36 +0800 Message-ID: <877g7xazhr.fsf@ericabrahamsen.net> References: <53212048.70901@siege-engine.com> <5321B561.2030004@online.de> <53224F2B.3070600@siege-engine.com> <532268F2.60809@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394789977 20520 80.91.229.3 (14 Mar 2014 09:39:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 09:39:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 10:39:46 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WOOaf-0006gI-2j for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 10:39:45 +0100 Original-Received: from localhost ([::1]:43666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOOae-0006wD-K2 for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 05:39:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOOaV-0006w8-Fi for emacs-devel@gnu.org; Fri, 14 Mar 2014 05:39:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOOaP-0002U7-3U for emacs-devel@gnu.org; Fri, 14 Mar 2014 05:39:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOOaO-0002U1-Sb for emacs-devel@gnu.org; Fri, 14 Mar 2014 05:39:29 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WOOaO-0006ON-6Y for emacs-devel@gnu.org; Fri, 14 Mar 2014 10:39:28 +0100 Original-Received: from 103.242.203.33 ([103.242.203.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Mar 2014 10:39:28 +0100 Original-Received: from eric by 103.242.203.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Mar 2014 10:39:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 103.242.203.33 User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:wwegHMYNWVbnnE6E8K25GcLPPyE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170344 Archived-At: Daniel Colascione 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!