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: Thu, 21 Mar 2002 19:39:37 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200203220039.g2M0dbj19729@rum.cs.yale.edu> References: <200203190844.g2J8iOq09224@wijiji.santafe.edu> <5xg02wd6cm.fsf@kfs2.cua.dk> <200203210904.g2L94HA10124@wijiji.santafe.edu> <200203211644.g2LGi3417793@rum.cs.yale.edu> <5x7ko5zosj.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 1016757739 13303 127.0.0.1 (22 Mar 2002 00:42:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2002 00:42:19 +0000 (UTC) Cc: "Stefan Monnier" , 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 16oD8N-0003SR-00 for ; Fri, 22 Mar 2002 01:42:19 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16oDEo-0004dF-00 for ; Fri, 22 Mar 2002 01:48:58 +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 16oD8F-0006Bw-00; Thu, 21 Mar 2002 19:42:11 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16oD5n-00063I-00 for ; Thu, 21 Mar 2002 19:39:39 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g2M0dbj19729; Thu, 21 Mar 2002 19:39:37 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: no-spam@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:2109 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2109 > > > Having make-network-process doing something other than making a > > > network process is not a more intuitive solution than featurep. > > > > > > That is exactly what bothers me about it. > > > > > > Perhaps we can implement use of lists as subfeatures. Then > > > (featurep 'make-network-process '(:family local)) could be used > > > instead of (make-network-process :feature :family 'local). > > > > I still haven't heard any evidence that > > > > (condition-case nil > > (make-network-process foo bar baz) > > (unsupported-networking-feature > > ...do..something..else...)) > > > > is not enough and that a separate `featurep' support is required. > > One example could be that we need to use different sentinels and > filters depending on what features are supported. Using the > featurep method, we only need to define the sentinel and filter > functions related to the actual method used. > > The condition-case approach means that you don't know in advance > what will be the optimal approach. I wasn't asking "can you think of a case where `featurep' would be useful" but "are there such cases". And I don't really care about cases where `featurep' would be marginally more convenient. For instance, I'm not convinced by your example: conditionally defining functions is not something I'd advocate anyway (unless you can put them in different files, but I doubt the sentinels and filters will be large enough to warrant my-server-nonblocking.el and myserver-blocking.el) so have both versions of the code defined is a perfectly acceptable overhead, just as is the overhead of having a single version of the functions with a dynamic check inside (I expect that the different versions of the sentinel and filter codes will be similar enough that there'll be a fair amount of code-sharing anyway). Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel