emacs-devel
[Top][All Lists]
Advanced

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

Re: Shrinking EIEIO objects


From: David Engster
Subject: Re: Shrinking EIEIO objects
Date: Fri, 02 Jan 2015 16:34:53 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux)

Eric Ludlam writes:
> On 01/02/2015 06:22 AM, David Engster wrote:
>> Eric Ludlam writes:
>>> On 12/30/2014 12:59 PM, Stefan Monnier wrote:
>>>> Hi Eric,
>
>>>>
>>>> I'd like to install something like the patch below into Emacs's master.
>>>> What it does (along with various other side changes) is shorten the
>>>> object header from 3 fields (the constant `object', the class name, and
>>>> an object "name" field) to just one (an interned symbol with an "eieio-"
>>>> prefix, referring to the class object).
>>> This seems like a fine idea.  A side effect is that the 'name' slot is
>>> gone.  There have received a questions about why there is a 'name' for
>>> objects, and really the main thing was debugging.  When you have piles
>>> of objects around, naming them makes it much easier to see what is
>>> going on.   EIEIO objects have a short hand using a #<class name>
>>> format, and when the various prin1 tools are enabled for edebug, that
>>> short hand is used in place of the vector.  This is critical when
>>> debugging semantic databases where the vectors contain thousands of
>>> symbols.
>>>
>>> Your proposed solution will enable the current source forge hosted
>>> version of CEDET to keep going, just with warning messages, which
>>> seems fine.
>>>
>>> I can convert the sourceforge version CEDET to use make-instance
>>> instead, which should be compatible before and after your change.
>> I'm a bit confused. Why would we need to change how we construct our
>> objects? Most of these changes seem to be purely internal. The only API
>> change I see (aside from the added eieio-- prefixes) is that NAME is now
>> optional (but not obsolete), which is certainly a good thing.
>
> In the patch, the generated constructor method calls 'message' if the
> first slot is a string (which is the now optional name input), and the
> message says the name input is obsolete, and also no longer saves the
> name.

Oh, I missed the call to 'message'... I just saw that the byte compile
is happy with or without name, but I guess it cannot detect this. And I
saw this comment

+;; In the past, every EIEIO object had a `name' field, so we had the two method
+;; below "for free".  Since this field is very rarely used, we got rid of it
+;; and instead we keep it in a weak hash-tables, for those very rare objects
+;; that use it.

which made me believe that NAME will stay supported. The name is saved
in the hash table `eieio--object-names', but `eieio-object-name' does
not return the name that was passed, so it doesn't seem to work.

Anyway, that means every package that uses EIEIO will spew out those
confusing messages at runtime, so everyone is pretty much forced to
rewrite it using `make-instance' so that it is compatible with older
versions. Stefan, please don't do that. What's so terrible about keeping
NAME as an optional argument?

-David



reply via email to

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