From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: EIEIO Date: Thu, 13 Mar 2014 23:35:17 -0400 Message-ID: <532278F5.8030404@siege-engine.com> 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; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1394768136 31877 80.91.229.3 (14 Mar 2014 03:35:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2014 03:35:36 +0000 (UTC) Cc: =?ISO-8859-1?Q?Andreas_R=F6hler?= , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 04:35:45 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 1WOIuP-00036x-1Y for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2014 04:35:45 +0100 Original-Received: from localhost ([::1]:42550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOIuO-0001TJ-Fl for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2014 23:35:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOIu9-0001Hg-Th for emacs-devel@gnu.org; Thu, 13 Mar 2014 23:35:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOIu1-0004ZW-2y for emacs-devel@gnu.org; Thu, 13 Mar 2014 23:35:29 -0400 Original-Received: from mail-qg0-x231.google.com ([2607:f8b0:400d:c04::231]:60704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOIu0-0004ZP-U7 for emacs-devel@gnu.org; Thu, 13 Mar 2014 23:35:21 -0400 Original-Received: by mail-qg0-f49.google.com with SMTP id z60so5774275qgd.8 for ; Thu, 13 Mar 2014 20:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AWT3Zzd767Wa+orFcz/gw3GgCuVExJP6q9B/qbklMcM=; b=OnAPSMPK7voR31RLzfxR5i8qcHI1m05GFB5DvLHC5PPeLuIYqHpdNm5+DChzgxukzw uR49snjETkui6qF6JouoIxRvvwrVNaqzQZJNP0uy1IH1hDjedCpCeY/9nclFWWxZzBJq Nar+E0EGFv5YgYk8+UHqVsR8axGKlOXy3OYuIAiR9JQI70TwzGad8hSnFshdugvZP2j9 7YgmqsjQdUPBhu82zYkwvXKjJMsSbbUmXPMgwq9v4DII2p/fBStCqDTgpPcGw95ss4/c YCZ4bbAxPl4hCP3zHPFlyvnee5iLPddOldAAD/CSUtdjAom+8WvclONPoqqrc+pfB8mZ lYFw== X-Received: by 10.140.92.6 with SMTP id a6mr6476921qge.34.1394768120181; Thu, 13 Mar 2014 20:35:20 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-71-184-209-46.bstnma.fios.verizon.net. [71.184.209.46]) by mx.google.com with ESMTPSA id q10sm12554363qaj.13.2014.03.13.20.35.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 20:35:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <532268F2.60809@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::231 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:170334 Archived-At: On 03/13/2014 10:26 PM, Daniel Colascione wrote: > 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? I was taking a C++ class and learning about OO systems and ORBs back when ORBs were new. It sounded like something useful for Emacs where I was having trouble building a precursor to CEDET, so I wrote EIEIO. I never did create the ORB though. I have vague recollections of trying to use defstructs back then, but they stymied me. > 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. EIEIO is not the best solution for all problems. It sounds like you had a problem that could be solved in a self contained system, so it didn't need to be organized with an extra level of abstraction that EIEIO provides. If you have a problem where you want to provide interfaces for external developers to code against, you will probably find EIEIO more useful. The learning curve is higher, sometimes debugging is more challenging if your have a lot methods overloading each other, but I've found it has served the goal of enabling several other developers to extend different parts of CEDET as intended, enabling them to implement complex behaviors (ie - wide interfaces) with no impact to the core. As for method dispatch, that is a long topic. Suffice it to say that EIEIO does not implement the CLOS pattern matching mechanism. It only does first argument dispatching which simplified the implementation, and was sufficient for what I was doing in CEDET. There are also 3 dispatch algorithms, so you can pick how you would like (call-next-method) to behave. There are also fun things like :BEFORE and :AFTER methods which are nifty. The more of those features you use, the longer it takes to execute those methods... naturally. If you only have one method with a particular name, then it is quite fast, ie - about 5 extra lines of code to execute, mostly error checking. Eric