all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Engster <deng@randomsample.de>
To: Eric Ludlam <ericludlam@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Shrinking EIEIO objects
Date: Fri, 02 Jan 2015 16:34:53 +0100	[thread overview]
Message-ID: <87d26xw602.fsf@engster.org> (raw)
In-Reply-To: <54A6B36C.20603@gmail.com> (Eric Ludlam's message of "Fri, 02 Jan 2015 10:04:12 -0500")

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	other threads:[~2015-01-02 15:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 17:59 Shrinking EIEIO objects Stefan Monnier
2015-01-02  2:40 ` Eric Ludlam
2015-01-02 11:22   ` David Engster
2015-01-02 15:04     ` Eric Ludlam
2015-01-02 15:34       ` David Engster [this message]
2015-01-03  2:11         ` Stefan Monnier
2015-01-03  9:55           ` David Engster
2015-01-04 19:34             ` Stefan Monnier
2015-01-09  5:44     ` Eric Abrahamsen
2015-01-09 15:11       ` Stefan Monnier
2015-01-10  2:03         ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d26xw602.fsf@engster.org \
    --to=deng@randomsample.de \
    --cc=emacs-devel@gnu.org \
    --cc=ericludlam@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.