help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: eieio persistent, plus autoloads


From: David Engster
Subject: Re: eieio persistent, plus autoloads
Date: Fri, 16 Aug 2013 17:18:23 +0200
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)

Eric Abrahamsen writes:
> That doesn't work because when users or third-party package managers
> want to subclass, say, the bbdb-field class, they would have to remember
> to do this:
>
> ;;;###autoload (eieio-defclass-autoload 'my-field-class "thisfile.el")

A plain ;;;###autoload is enough; the autoload-updating mechanism will
see that it is for a defclass.

Otherwise: Yes, the package maintainer should put an autoload comment on
functions which are likely to be used before the package is loaded, and
the same best practice applies to classes.

I don't see this being specific to EIEIO. In general, how do you make
sure a package is loaded before you use it? In Emacs, you usually
require it in your .emacs; for big packages, like Gnus or CEDET, that
require simply loads a file filled with autoloads, which were generated
during their compilation. For small packages, it is usually tolerable to
simply load the whole thing on startup. (I happen to create an autoload
file for all those little packages, but I think that's pretty unusual,
and I also wouldn't recommend it to people unfamiliar with Emacs
autoloads.)

> It just seems a lot safer to have something automatic.

No, on the contrary. One package fiddling with autoloads from another
package is asking for trouble. What if I happen to load a package and it
creates a class which inherits from bbdb-field, and I don't even know
that? If would put a permanent autoload into my BBDB setup, that would
annoy me immensely. What happens if I remove that package?

> So I was thinking either hot-wire `defclass' (probably with advice)
>, or provide a special macro for subclassing these classes. But both of
>those solutions have the same problem: as far as I can tell, calling
>`eieio-defclass-autoload' in a program, followed by
>`update-file-autoloads', does *not* write anything to a loaddef file,
>that only happens when compiling a file with autoload cookies in it.

Yes, it's the same with plain `autoload'. `update-file-autoloads' is
just a mechanism so that you don't have to manually write and maintain a
file containing all the autoloads of your package.

> So... now I'm thinking that, if I really want to insist on this, I'll
> still go the macro route, but just use some of the bits and pieces from
> autoload.el and cobble together something semi-manual.

IMHO it's really simple: If you're using a third-party package which
extends BBDB, it has to be loaded before you load your bbbdb file. The
user should take care of that, and I don't think that's asking too
much. :-)

-David




reply via email to

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