Re: Cleaning up the EIEIO namespace

[David Engster]

Stefan Monnier writes:
>> I didn't have time yet to look at your patch in detail.  I did apply it
>> to CEDET trunk and got byte-compile errors because there's
>> eieio-class-parent as well as eieio--class-parent.
>
> Hmm.. there are both eieio-class-parent as well as eieio--class-parent,
> but I'm not sure why that would cause a byte-compile error.

In toplevel form:
eieio.el:168:1:Error: Symbol's function definition is void: eieio--class-parent

I also cannot find a definition for eieio--class-parent, but maybe it's
hidden somewhere?

> 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...?

-David