[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cedet-eieio] Cleaning up the EIEIO namespace

From: Eric M. Ludlam
Subject: Re: [cedet-eieio] Cleaning up the EIEIO namespace
Date: Wed, 13 Feb 2013 20:11:05 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]