From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Le Wang Newsgroups: gmane.emacs.devel Subject: Re: when to call provide, first or last? Date: Mon, 27 Feb 2012 21:42:34 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0418266262be3204b9f2482c X-Trace: dough.gmane.org 1330350173 14854 80.91.229.3 (27 Feb 2012 13:42:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Feb 2012 13:42:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 27 14:42:52 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S20qn-0003a2-7S for ged-emacs-devel@m.gmane.org; Mon, 27 Feb 2012 14:42:49 +0100 Original-Received: from localhost ([::1]:35408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20qm-0002vd-Rn for ged-emacs-devel@m.gmane.org; Mon, 27 Feb 2012 08:42:48 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20qg-0002vU-1k for emacs-devel@gnu.org; Mon, 27 Feb 2012 08:42:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S20qZ-0006KC-Vr for emacs-devel@gnu.org; Mon, 27 Feb 2012 08:42:41 -0500 Original-Received: from mail-we0-f169.google.com ([74.125.82.169]:51069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20qZ-0006K7-O0 for emacs-devel@gnu.org; Mon, 27 Feb 2012 08:42:35 -0500 Original-Received: by werj55 with SMTP id j55so611108wer.0 for ; Mon, 27 Feb 2012 05:42:34 -0800 (PST) Received-SPF: pass (google.com: domain of l26wang@gmail.com designates 10.180.86.105 as permitted sender) client-ip=10.180.86.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of l26wang@gmail.com designates 10.180.86.105 as permitted sender) smtp.mail=l26wang@gmail.com; dkim=pass header.i=l26wang@gmail.com Original-Received: from mr.google.com ([10.180.86.105]) by 10.180.86.105 with SMTP id o9mr28363851wiz.4.1330350154635 (num_hops = 1); Mon, 27 Feb 2012 05:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sXLxgoGemFuEYARbwdaOUEORTBLi7SUXBXukVMUFNF8=; b=RkZE0namOTgRMogFaYPYu0t2QAER0Fw0XAXHYmU9imIYmh+ZNFa5qLZindRFmWTJh1 1RFIIRSsaUNX4xzzHoT1dBCSiPSeSIr6VSUuj5kGVwkdx+ds7npxNAFVECeqyKavTtkU RixWmQcoA0NeNMko9ZSTwDcX2c3TpaDeH1l6Y= Original-Received: by 10.180.86.105 with SMTP id o9mr22548906wiz.4.1330350154497; Mon, 27 Feb 2012 05:42:34 -0800 (PST) Original-Received: by 10.216.29.130 with HTTP; Mon, 27 Feb 2012 05:42:34 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148815 Archived-At: --f46d0418266262be3204b9f2482c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 27, 2012 at 9:35 PM, Stefan Monnier wrote: > Actually, such mutual dependencies aren't desirable Can you elaborate on this a little? In my mind if two files implement different parts of the same libraby, it's quite natural for mutual dependencies to occur. > : sometimes they're > hard to avoid so we prefer to live with them, but that doesn't change > the fact that they're not good. > > Putting the provide at the end makes sure that if featurep says t, then > it means thatthe feature is actually available, whereas if it's at the > beginning, featurep returning t only mean "we've started to lead the > feature, and well, maybe we've actually loaded it all by now, but I'm > not sure". > > The difference is sufficiently unimportant to deserve bikeshedding, > cool word -> bikeshedding > I guess, but in any case, the convention is to put it at the end. > Like every convention, there can be exceptional circumstances that > justify doing it differently, but they have to be exceptional rather > than only based on taste. > > > Stefan > -- Le --f46d0418266262be3204b9f2482c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2012 at 9:35 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
Actually, such mutual dependencies aren't desirable
Can you elaborate on this a little?=A0 In my mind if two files implement = different parts of the same libraby, it's quite natural for mutual depe= ndencies to occur.
=A0
: sometimes they= 're
hard to avoid so we prefer to live with them, but that doesn't change the fact that they're not good.

Putting the provide at the end makes sure that if featurep says t, then
it means thatthe feature is actually available, whereas if it's at the<= br> beginning, featurep returning t only mean "we've started to lead t= he
feature, and well, maybe we've actually loaded it all by now, but I'= ;m
not sure".

The difference is sufficiently unimportant to deserve bikeshedding,

cool word -> bikeshedding
=A0
I guess, but in any case, the convention is to put it at the end.
Like every convention, there can be exceptional circumstances that
justify doing it differently, but they have to be exceptional rather
than only based on taste.


=A0 =A0 =A0 =A0Stefan



--
Le
--f46d0418266262be3204b9f2482c--