From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: featurep Date: 20 Mar 2002 00:48:40 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xwuw8xgo7.fsf@kfs2.cua.dk> References: <200203190844.g2J8iOq09224@wijiji.santafe.edu> <5xg02wd6cm.fsf@kfs2.cua.dk> <200203192120.g2JLKVQ08387@rum.cs.yale.edu> <5x7ko8yx1y.fsf@kfs2.cua.dk> <200203192319.g2JNJMO09092@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016675418 27490 127.0.0.1 (21 Mar 2002 01:50:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2002 01:50:18 +0000 (UTC) Cc: Jason Rumney , rms@gnu.org, emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16nric-00079H-00 for ; Thu, 21 Mar 2002 02:50:18 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16nroc-0002nG-00 for ; Thu, 21 Mar 2002 02:56:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16nriR-0006tc-00; Wed, 20 Mar 2002 20:50:07 -0500 Original-Received: from delysid.gnu.org ([158.121.106.20]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16nozt-0005A1-00; Wed, 20 Mar 2002 17:55:57 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by delysid.gnu.org with smtp (Exim 3.34 #2) id 16nTXC-0006K5-00; Tue, 19 Mar 2002 19:00:54 -0500 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id E925A7C047; Tue, 19 Mar 2002 23:47:42 +0000 (GMT) Original-To: "Stefan Monnier" In-Reply-To: <200203192319.g2JNJMO09092@rum.cs.yale.edu> Original-Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2073 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2073 "Stefan Monnier" writes: > > Ok, but if you combine :family 'local and :datagram t, and > > make-network-process returns nil, you really don't know whether it's > > because it doesn't support local sockets or datagrams -- so what would > > you try next? > > Why does it matter ? > What would the code look like using your :feature thing ? Probably not a lot different, but without checking for a feature first, the current code will throw an error for an unsupported feature indicating (in clear text) what the problem is. Suppose you write a package using datagrams, and don't handle the case where it returns nil (as you suggest). In that case, a user of your package will just see things not working (which he can report to you as "it doesn't work"), rather than make-network-process throwing a "datagrams not supported" error (which will probably give you a better understanding of the problem when he reports that to you). > Most likely your code can handle a small fixed number of different > combination of features. It can use :feature to decide which one > of the alternatives to choose or it can just try them in order > until one of them succeeds. > I.e. I don't see how the "what would you try next" question is relevant > since the problem also shows up with :feature. No, but I disagree with the return nil and try next approach. > > > In any case, I disagree, but I don't want to be religious about this, > > so I'll change the code to use featurep. > > Is it even necessary ? > I expect that "try-it-and-see" will already catch all relevant cases. So, yes, if you as a package author is aware of the possibility that make-network-process returns nil on some systems for some combination of features, than everything's fine. But if some other package author isn't aware of this, it can be a hard bargain trying to figure out what went wrong (as the author and the user obviously are not on the same platform). > I'm really not convinced that we need anything more, so I wouldn't > bother with anything more until there's some evidence that it > is needed. Of course, maybe you have that evidence, but I haven't seen it. IMO, being such a multi-facetted beast, make-network-process should throw exceptions when an unsupported feature is used. If it didn't do that, debugging code using it would be difficult. Your proposal takes that away (to remove a useful, but unclean :feature :-). -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel