unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: herring@lanl.gov
Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
Subject: Re: Is (provide 'foo) at the start good or bad?
Date: Tue, 16 Jun 2009 12:47:28 +0900	[thread overview]
Message-ID: <874ouglu0f.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <42424.130.55.118.19.1245090041.squirrel@webmail.lanl.gov>

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	other threads:[~2009-06-16  3:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11 12:56 Is (provide 'foo) at the start good or bad? William Xu
2009-06-11 17:01 ` Leo
2009-06-12  4:09   ` Stephen J. Turnbull
2009-06-12  5:01     ` William Xu
2009-06-12 10:02       ` Thien-Thi Nguyen
2009-06-12 10:26       ` Stephen J. Turnbull
2009-06-12 15:15         ` William Xu
2009-06-12  8:36     ` Alan Mackenzie
2009-06-12 10:10       ` Stephen J. Turnbull
2009-06-12 23:00     ` Davis Herring
2009-06-13 12:19       ` Stephen J. Turnbull
2009-06-14 19:30         ` Davis Herring
2009-06-15  3:04           ` Stephen J. Turnbull
2009-06-15 18:20             ` Davis Herring
2009-06-16  3:47               ` Stephen J. Turnbull [this message]
2009-06-12 21:16 ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=874ouglu0f.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=emacs-devel@gnu.org \
    --cc=herring@lanl.gov \
    --cc=sdl.web@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).