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 16:20:31 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200203192120.g2JLKVQ08387@rum.cs.yale.edu> References: <200203190844.g2J8iOq09224@wijiji.santafe.edu> <5xg02wd6cm.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 1016572888 3099 127.0.0.1 (19 Mar 2002 21:21:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 21:21:28 +0000 (UTC) Cc: storm@cua.dk (Kim F. Storm), 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 16nR2t-0000nt-00 for ; Tue, 19 Mar 2002 22:21:27 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16nR8L-0001Z6-00 for ; Tue, 19 Mar 2002 22:27:05 +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 16nR2f-0005ea-00; Tue, 19 Mar 2002 16:21:13 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16nR1z-0005bg-00; Tue, 19 Mar 2002 16:20:31 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g2JLKVQ08387; Tue, 19 Mar 2002 16:20:31 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Jason Rumney 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:2049 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2049 > storm@cua.dk (Kim F. Storm) writes: > > > However, for a usage point of view, I don't really see why it > > matters, and IMHO, using featurep will be _less_ intuitive. > > For example, I think using > > > > (if (and (make-network-process :feature :family 'local) > > (make-network-process :feature :datagram t)) > > Having make-network-process doing something other than making a > network process is not a more intuitive solution than featurep. Agreed. I also agree that `featurep' is not a perfect answer, tho. Ideally, what I'd like is something like (featuredp '(make-network-process :family 'local)) 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. 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. Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel