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, 20 Feb 2013 18:41:35 -0500 Message-ID: <51255F2F.7060707@siege-engine.com> References: <87sj51fakd.fsf@engster.org> <87k3qcfa4x.fsf@engster.org> <511C39A9.4000403@siege-engine.com> <874nhefvcr.fsf@engster.org> <87a9r18g15.fsf@engster.org> <87621o84pd.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 1361403705 26610 80.91.229.3 (20 Feb 2013 23:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 23:41:45 +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 21 00:42:07 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 1U8JIc-0008PE-3s for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2013 00:42:06 +0100 Original-Received: from localhost ([::1]:60732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8JIH-0000PG-VG for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 18:41:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8JIE-0000PA-GI for emacs-devel@gnu.org; Wed, 20 Feb 2013 18:41:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8JIB-0001J9-La for emacs-devel@gnu.org; Wed, 20 Feb 2013 18:41:42 -0500 Original-Received: from mail-vb0-f41.google.com ([209.85.212.41]:54748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8JIB-0001Iy-Gr for emacs-devel@gnu.org; Wed, 20 Feb 2013 18:41:39 -0500 Original-Received: by mail-vb0-f41.google.com with SMTP id l22so5452966vbn.28 for ; Wed, 20 Feb 2013 15:41:38 -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=iydg0vNKfZPplnrPdGMURtoagHSnGZsWwMKed/2ONnY=; b=R+UkUVHwYL48bQfcP2o9Epmrq/W74rmBumuphqanP5AxdidRTovjq/Qi26JmAbS2BP NM3t8pfC3FNXB+zrLdNw9L7PYiHyy7MiBS+vFOXqfSlhidMP8fwqGQgQXZPIE8agyaim 34z3WK6OCT4/7OzFjtPboKnOJWtgM1m2dTowN13y+m54QFBCnsagNh+pktBKhG5gfMhP QxlEvi4mnTuuAY417B+1GEwu27c1ZYgT0gZGQoTtCnkVH171wlsX9L6Q5gE1Xpp08cHZ Qo3eDJw4BxgVeUEQbqNaXkJg0nRpgYm42kNQLIcCvkt8s2LaxWkXf6cAheD2q19kxW5e BfdA== X-Received: by 10.220.149.82 with SMTP id s18mr28678822vcv.14.1361403698437; Wed, 20 Feb 2013 15:41:38 -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 l5sm1997954vdi.4.2013.02.20.15.41.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 15:41:37 -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: <87621o84pd.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.212.41 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:157227 gmane.emacs.eieio:153 Archived-At: On 02/19/2013 02:49 PM, David Engster wrote: > Stefan Monnier writes: >> 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. There is nothing in eieio-base from CLOS. Those are all just handy base-classes / concepts that I used elsewhere in CEDET. > 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). I am fine with most of these ideas, but agree with David that option 3 is pretty good. Eric