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: Eric Abrahamsen
Subject: Re: eieio persistent, plus autoloads
Date: Sat, 17 Aug 2013 12:11:39 +0800
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)

David Engster <deng@randomsample.de> writes:

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

Okay, I guess I get it. I was thinking of eieio-persistent as a slightly
unusual case just because object constructors are being written to a
file, and the potential for breakage seems a little more dramatic. But
perhaps some nice error handling and reporting is all that's necessary.

Just out of curiosity, how do you create an autoload file for your
smaller packages?

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

Good point!

>> 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. :-)

Cool, this makes sense. I guess I half-expected, when I posted this, to
be told I was barking up the wrong tree entirely, and I'm pleased to get
another opinion on best practices.

Thanks!
Eric




reply via email to

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