From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: featurep Date: Tue, 19 Mar 2002 18:19:22 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200203192319.g2JNJMO09092@rum.cs.yale.edu> References: <200203190844.g2J8iOq09224@wijiji.santafe.edu> <5xg02wd6cm.fsf@kfs2.cua.dk> <200203192120.g2JLKVQ08387@rum.cs.yale.edu> <5x7ko8yx1y.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016679753 32342 127.0.0.1 (21 Mar 2002 03:02:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2002 03:02:33 +0000 (UTC) Cc: "Stefan Monnier" , 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 16nsqX-0008PX-00 for ; Thu, 21 Mar 2002 04:02:33 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16nswZ-0003LT-00 for ; Thu, 21 Mar 2002 04:08:47 +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 16nrZl-0005te-00; Wed, 20 Mar 2002 20:41:09 -0500 Original-Received: from delysid.gnu.org ([158.121.106.20]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16np1q-0005A1-00; Wed, 20 Mar 2002 17:57:59 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by delysid.gnu.org with esmtp (Exim 3.34 #2) id 16nSw9-0005sA-00; Tue, 19 Mar 2002 18:22:37 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g2JNJMO09092; Tue, 19 Mar 2002 18:19:22 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: storm@cua.dk (Kim F. Storm) 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:2080 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2080 > > where `featuredp' simply takes a function together with a set of > > arguments and returns whether or not that call is "supported". > > It would first check the fboundness of the function, the number of arguments > > and all those things. > > I think this would be overkill. If we go that route, then it should > apply to all functions Yes, that was my intention. > and that has never been the intention. No, indeed, I understand that it is way past any immediate concern and as I said, I have no clue how to implement such a thing. > > But I have no good idea how to go about implementing this thing, so > > as a first step, I think that it should be good enough just to make > > `make-network-process' fail when called with arguments requiring > > unsupported features. After all, it's generally the case that if > > the feature is supported, then we do want to make the function call, > > so we might as well call the function and see if it worked. > > 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 ? 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. > 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. 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. Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel