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,gmane.emacs.eieio Subject: Re: [cedet-eieio] Cleaning up the EIEIO namespace Date: Wed, 13 Feb 2013 20:11:05 -0500 Message-ID: <511C39A9.4000403@siege-engine.com> References: <87sj51fakd.fsf@engster.org> <87k3qcfa4x.fsf@engster.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 1360804280 10450 80.91.229.3 (14 Feb 2013 01:11:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Feb 2013 01:11:20 +0000 (UTC) To: Stefan Monnier , cedet-eieio@lists.sourceforge.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 14 02:11:42 2013 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 1U5nMN-0003q6-5r for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2013 02:11:35 +0100 Original-Received: from localhost ([::1]:44156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5nM3-0007tO-C4 for ged-emacs-devel@m.gmane.org; Wed, 13 Feb 2013 20:11:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5nLz-0007sm-V2 for emacs-devel@gnu.org; Wed, 13 Feb 2013 20:11:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5nLy-0006BO-Ek for emacs-devel@gnu.org; Wed, 13 Feb 2013 20:11:11 -0500 Original-Received: from mail-ve0-f172.google.com ([209.85.128.172]:55359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5nLy-0006BB-8s for emacs-devel@gnu.org; Wed, 13 Feb 2013 20:11:10 -0500 Original-Received: by mail-ve0-f172.google.com with SMTP id cz11so1678144veb.17 for ; Wed, 13 Feb 2013 17:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GKUktg6jVin+UoQdZqko+2Sz9qWNeD4UtyaZhV/D950=; b=whIJJ7s2b8WoRmaHlv+z55x41PB17N1j4bVYYxKB6Ywgq9LhMsJA7bk76pRoMhbBmM StNbpairfn1JQaT/PAmbrZVpeu+SDULIPq51wFC9NgZLEZBP30ucNTSkmFNy8u0elnu8 8u9WYzfRIbdK4juZLUb5EoG0Ar1hS0D86rqZnArE+XBfrG8P7yxPRALoH060En06Fmhl JTdURYx5kPKtAhySjheZyjkCsioa2PnYNgaB1bZp9LbgRQLb0ZMN+BIJRgCgiXCLh/tt tSrCBF6toJ4n6cpRrTrcA1+ZUtkBWJc7RBv7p60tjkib7yJrQwinjMg+I1I5FlPXM5fu oZ4w== X-Received: by 10.52.33.228 with SMTP id u4mr27570873vdi.4.1360804268888; Wed, 13 Feb 2013 17:11:08 -0800 (PST) Original-Received: from [192.168.1.201] (pool-72-74-140-235.bstnma.fios.verizon.net. [72.74.140.235]) by mx.google.com with ESMTPS id kn18sm72695557veb.5.2013.02.13.17.11.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 17:11:07 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87k3qcfa4x.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.128.172 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:157017 gmane.emacs.eieio:137 Archived-At: On 02/13/2013 11:31 AM, David Engster wrote: > Stefan Monnier writes: >> I don't know CLOS either. I also don't know EIEIO enough to know for >> sure which functions are "internal" (and can hence move to "eieio-" or >> even "eieio--" without any problem) and which are "exported", so that >> renaming them has to be done more carefully (with obsolete aliases). > > Eric already posted links to the hyperspec where this can be looked > up. From your bug report #10781, the following names are from CLOS: > > * Most of the slot-* names, like slot-boundp, slot-exists-p, etc. > * make-instance, initialize-instance > * with-slots > * class-name, class-of > * next-method-p, call-next-method > * defgeneric, defclass, defmethod > > Now, whether to include them in the cl- or the eieio-namespace - I don't > have a terribly strong opinion on that one. If it's deemed too hack-ish, > then so be it, and we just prefix everything with eieio-. [Eric, if you > feel more strongly about those names, then please speak up. :-) ] > > Actually, the most critical thing is 'oref' and 'oset', because this is > used extensively (~1800 times in CEDET), and it is not from > CLOS. Prefixing that with 'eieio-' would make code using EIEIO very > verbose, but I guess there's just no way around that...? I'm fine with renaming most EIEIO unique items with some eieio- flavor of prefix. I know there is a debate of cl- vs eieio-. Drew summed up well that EIEIO is an emulation of a subset of the OO parts of CLOS. I think it is incomplete, particularly since it doesn't handle important aspects of method polymorphism, such as allowing method differentiation based on multiple input arguments, or against built-in types such as string or number. Thus, my vote would be for an eieio- prefix since someday a better cl- or clos- variant might appear. As for the names of CLOS methods, such as make-instance, etc. Personally, I think they should be left alone, but recognize that being a part of Emacs can come with a naming cost. Unfortunately, that makes it hard to differentiate between CLOS parts and misc eieio internal parts. I also think of oref/oset in the same bin as CLOS names such as make-instance, etc. CLOS examples all use slot-value/setf instead of oref/oset. setf is part of cl, and couldn't be used at runtime, so I mocked up the behavior with something matching aref/aset instead. They are used all the time, and need a convenient name. Having oref/oset use a different naming convention from the names from CLOS API would be inconvenient. Eric