Re: Cleaning up the EIEIO namespace

Stefan Monnier writes:
>>> Actually, there's a misunderstanding here:
>>> - setf was indeed part of CL, but being a macro it was accepted
>>> (i.e. you don't need to have it defined at run-time, since it's
>
>>> macro-expanded during compilation).
>>> - setf is part of core Elisp in Emacs-24.3.
>>> So maybe we don't need oref/oset at all.
>> Yes, although I like "(oset foo bar 'baz)" much better than the verbose
>> (setf (cl-slot-value foo 'bar) 'baz)
>> But I can understand that you want to get rid of it, and package writers
>> can still define their own macros/accessors.
>
> I actually don't particular care if we keep them or not, except that if
> we keep them, we need to give them a prefix.

OK. I guess we'd have to use eieio-oref/oset then, since those functions
are not from CLOS (given that 'cl' means that thing I thought it means,
but I might just be confused :) ).

>> Our problem on the CEDET side is that we want to stay compatible with
>> older Emacsen, so we'll need some compat package.
>
> We can either introduce an eieio-compat package full of defaliases, or
> do what we did with cl/cl-lib and turn eieio.el into a deprecated compat
> package (and introduce a new package eieio-lib to replace it).

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?

-David

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/