From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.eieio,gmane.emacs.devel Subject: Re: Cleaning up the EIEIO namespace Date: Tue, 19 Feb 2013 20:49:02 +0100 Message-ID: <87621o84pd.fsf@engster.org> References: <87sj51fakd.fsf@engster.org> <87k3qcfa4x.fsf@engster.org> <511C39A9.4000403@siege-engine.com> <874nhefvcr.fsf@engster.org> <87a9r18g15.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361303364 12925 80.91.229.3 (19 Feb 2013 19:49:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2013 19:49:24 +0000 (UTC) Cc: emacs-devel@gnu.org, cedet-eieio@lists.sourceforge.net, "Eric M. Ludlam" To: Stefan Monnier Original-X-From: cedet-eieio-bounces@lists.sourceforge.net Tue Feb 19 20:49:44 2013 Return-path: Envelope-to: sf-cedet-eieio@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7tC7-00022g-Ku for sf-cedet-eieio@m.gmane.org; Tue, 19 Feb 2013 20:49:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U7tBm-0000HL-CD; Tue, 19 Feb 2013 19:49:18 +0000 Original-Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U7tBk-0000HC-RM for cedet-eieio@lists.sourceforge.net; Tue, 19 Feb 2013 19:49:16 +0000 X-ACL-Warn: Original-Received: from randomsample.de ([83.169.19.17]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1U7tBf-0000q1-P4 for cedet-eieio@lists.sourceforge.net; Tue, 19 Feb 2013 19:49:16 +0000 Original-Received: from dslc-082-083-033-249.pools.arcor-ip.net ([82.83.33.249] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U7tBX-0005Gr-Lm; Tue, 19 Feb 2013 20:49:03 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 18 Feb 2013 22:26:41 -0500") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux) Mail-Followup-To: Stefan Monnier , "Eric M. Ludlam" , cedet-eieio@lists.sourceforge.net, emacs-devel@gnu.org X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1U7tBf-0000q1-P4 X-BeenThere: cedet-eieio@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cedet-eieio-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.eieio:151 gmane.emacs.devel:157166 Archived-At: Stefan Monnier writes: >> I meant a compat package in CEDET upstream, so that it can run on older >> Emacsen if we stop shipping our own EIEIO version. As long as we're >> obsolete-aliasing the old names, I don't see why we would need a compat >> package in Emacs? > > Only if we can hope to get rid of those aliases soon, because we'd > rather not have those compatibility aliases use up the namespace even > when all the packages in use have been updated to use the "clean" names. Well, you've started aliasing `class-name' in your patch, so I thought that was the plan. > For the CL package we solved this problem by leaving the "cl.el" package > as a "compatibility package" only required by the packages that haven't > been updated to use the new names. CL was so widely used that it will > take a *long* time to get rid of all uses of the old names, whereas > EIEIO's use is not as pervasive, so we don't necessarily have to do the > same for it. > This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el" > (with clean names, autoloaded from cl-lib) and then make eieio.el > into a simple compatibility package full of aliases. What to do with the other files like eieio-base then? We cannot rename it to cl-eieio-base.el because of name clashes, but it also provides part of the public, CLOS-like functions. To summarize the options so far: 1) Prefix everything with eieio- and be done with it. Create obsolete aliases for the old names and get rid of them "soon" (Emacs 25?). Alternatively, create an eieio-compat package with aliases for the old names. 2) Prefix everything with eieio- and create cl- aliases for the CLOS-like functionality. Those aliases may be defined in 2a) the eieio* files itself, or 2b) in a separate cl-whatever.el file. As in 1), define obsolete aliases for the old names or use a compat package. 3) Rename eieio to cl-eieio with clean names (i.e., eieio- and cl-prefixes), autoloaded from cl-lib, and make eieio.el a simple compatibility package full of aliases. I'm currently pretty much tied on "2b)+compat package" and 3). -David ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb