From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Is (provide 'foo) at the start good or bad? Date: Tue, 16 Jun 2009 12:47:28 +0900 Message-ID: <874ouglu0f.fsf@uwakimon.sk.tsukuba.ac.jp> References: <21glws7jx732.fsf@gmail.com> <87r5xqw0s8.fsf@uwakimon.sk.tsukuba.ac.jp> <49293.130.55.118.19.1244847603.squirrel@webmail.lanl.gov> <87eitowck5.fsf@uwakimon.sk.tsukuba.ac.jp> <51511.130.55.118.19.1245007816.squirrel@webmail.lanl.gov> <877hzeci43.fsf@uwakimon.sk.tsukuba.ac.jp> <42424.130.55.118.19.1245090041.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1245123955 16776 80.91.229.12 (16 Jun 2009 03:45:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Jun 2009 03:45:55 +0000 (UTC) Cc: Leo , emacs-devel@gnu.org To: herring@lanl.gov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 16 05:45:51 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MGPcN-0000TJ-5N for ged-emacs-devel@m.gmane.org; Tue, 16 Jun 2009 05:45:51 +0200 Original-Received: from localhost ([127.0.0.1]:42751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGPcM-0000Kq-H3 for ged-emacs-devel@m.gmane.org; Mon, 15 Jun 2009 23:45:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGPcH-0000Hs-Gp for emacs-devel@gnu.org; Mon, 15 Jun 2009 23:45:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGPcC-0000HX-1i for emacs-devel@gnu.org; Mon, 15 Jun 2009 23:45:44 -0400 Original-Received: from [199.232.76.173] (port=55771 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGPcB-0000HU-Rw for emacs-devel@gnu.org; Mon, 15 Jun 2009 23:45:39 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:57848) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGPcB-0003zx-3V for emacs-devel@gnu.org; Mon, 15 Jun 2009 23:45:39 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7176A1537C0; Tue, 16 Jun 2009 12:45:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0A441128CF6; Tue, 16 Jun 2009 12:47:29 +0900 (JST) In-Reply-To: <42424.130.55.118.19.1245090041.squirrel@webmail.lanl.gov> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111537 Archived-At: 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.