emacs-devel
[Top][All Lists]
Advanced

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

Re: Is (provide 'foo) at the start good or bad?


From: Stephen J. Turnbull
Subject: Re: Is (provide 'foo) at the start good or bad?
Date: Tue, 16 Jun 2009 12:47:28 +0900

Davis Herring writes:

 > > No.  You're missing the "multiple versions" case.
 > 
 > (I think most of the productive ideas here have been stated.  Purely for
 > my edification:)  Why, if we have Av1 and Bv1, neither of which requires
 > the other (or at least only one requires the other), and Av2 and Bv2,
 > which are mutually dependent, can't we merge only the latter

Emacs can, because Emacs offers neither support for 3rd party packages
nor support for previous versions of Emacs.  XEmacs cannot, because we
offer support for both.

That is, Emacs has a policy of doing what is best for Emacs, and if
third parties feel ill-used, let them integrate their code and Emacs
will of course ensure that their code works well in future versions of
Emacs.  Not everybody want to integrate their code into anything,
however.  XEmacs (and SXEmacs, AFAIK) deliberately encourages 3rd
parties to develop their projects separately, while providing tools to
integrate them smoothly at runtime.

 > Later you said that the (mutually-dependent versions of the) libraries
 > might continue to be developed separately.  That seems odd to me,

That doesn't surprise me.  There are a fair number of people in this
world who don't think that "odd" is a good reason to restrict freedom,
however, and even a few who act on the freedom thus granted.

 > since they will always be loaded together, and they might need to
 > be upgraded together.

"Always" is too strong; see the third option of `require'.

 > But if it does happen, then perhaps the right thing is to put
 > `require's as late as possible and `provide's right before them, so
 > that both mutual recursion and `eval-after-load' will work (most of
 > the time).

`eval-after-load' is an optimization.  Anything that can be done with
`eval-after-load' can be done with `require-before-doing'. :-)  The
right thing is to fix `eval-after-load' to wait until all loading is
done, then its environment should be in place, and it can do its
thing.

I don't know how to do this offhand, though.




reply via email to

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