From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: ewoc patch Date: Thu, 10 Dec 2009 02:28:17 -0500 Message-ID: References: <08698ba442eec12008bede6987588958.squirrel@mail.panix.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260430131 17089 80.91.229.12 (10 Dec 2009 07:28:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2009 07:28:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Tom Breton \(Tehom\)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 08:28:44 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 1NIdRw-0000aC-1P for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 08:28:32 +0100 Original-Received: from localhost ([127.0.0.1]:50859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIdRv-0006Kz-JK for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 02:28:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIdRp-0006KS-BY for emacs-devel@gnu.org; Thu, 10 Dec 2009 02:28:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIdRk-0006IC-1m for emacs-devel@gnu.org; Thu, 10 Dec 2009 02:28:24 -0500 Original-Received: from [199.232.76.173] (port=40019 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIdRj-0006I3-SF for emacs-devel@gnu.org; Thu, 10 Dec 2009 02:28:19 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:56367 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIdRj-0002Qa-Jo for emacs-devel@gnu.org; Thu, 10 Dec 2009 02:28:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYEAEYyIEtMCpT8/2dsb2JhbACBS9M0hCwEihw X-IronPort-AV: E=Sophos;i="4.47,374,1257138000"; d="scan'208";a="51302926" Original-Received: from 76-10-148-252.dsl.teksavvy.com (HELO pastel.home) ([76.10.148.252]) by ironport2-out.pppoe.ca with ESMTP; 10 Dec 2009 02:28:17 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B50638065; Thu, 10 Dec 2009 02:28:17 -0500 (EST) In-Reply-To: <08698ba442eec12008bede6987588958.squirrel@mail.panix.com> (Tom Breton's message of "Wed, 9 Dec 2009 23:52:56 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:118513 Archived-At: > How do you prefer to handle the part of the ewoc-create interface that > gives separator? I can see several ways of proceeding: > * Add another optional argument. So there'd be both "nosep" and > "separator" > * Con: It's ugly to have 2 arguments with strongly overlapping > meanings. > * Con: Confusing if the given arguments disagree. > * Replace argument "nosep" with "separator" > * Con: Breaks backward compatibility. > * Pro: Suffices to control all the variability > * Keep only "nosep" as an argument. > * Con: The flexibility is not available, though it exists internally. > * Provide two function signatures; maybe name the other > `ewoc-create*'. > * Con: Makes the interface a little bigger. Keep only `separator', but with the added twist that a non-string, non-nil argument means the empty string (aka mean "nosep"). That should preserve backward compatibility with a mostly clean API. >>>> The Emacs package generally doesn't like version numbers, so I'd rather >>>> not introduce one here, unless there's really a good reason for it. >>> I added it so that other packages that wanted or needed a variable >>> separator could tell whether it was available. Otherwise they would >>> make >>> errors if an old ewoc.el was loaded. If you have a better way in mind, >>> I'll use it. >> Better just try to use the feature and detect when it's not available. >> E.g. check the feature's presence via `fboundp' or by trying the call >> with the extra parametwer and catch the >> `wrong-number-of-arguments' error. > I'm not sure that would suffice. ewoc-create is fbound in any case. That > leaves us with trying ewoc-create and catching the error. My fear is that > a client's call to ewoc-create would not naturally occur at a good time > for this. Ie, a client would appear to load correctly, would be started > by the user, and only then realize that it was relying on something that > wasn't available. I think you're worrying for no good reason. If you really want to handle version dependencies right, you don't want it in a Lisp variable but in a header understood and processed by some package manager (ELPA, for instace). Otherwise, you'll have to deal (one way or another) with runtime checks, and in most cases the calling package will simply not work with an older version. Stefan