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: 19 Mar 2002 14:39:37 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xg02wd6cm.fsf@kfs2.cua.dk> References: <200203190844.g2J8iOq09224@wijiji.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016545174 1953 127.0.0.1 (19 Mar 2002 13:39:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Mar 2002 13:39:34 +0000 (UTC) Cc: 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 16nJpu-0000VP-00 for ; Tue, 19 Mar 2002 14:39:34 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16nJvC-0006Ab-00 for ; Tue, 19 Mar 2002 14:45:02 +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 16nJpY-0000Xs-00; Tue, 19 Mar 2002 08:39:12 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16nJp3-0000Or-00; Tue, 19 Mar 2002 08:38:41 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 2E1EE7C035; Tue, 19 Mar 2002 13:38:39 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200203190844.g2J8iOq09224@wijiji.santafe.edu> Original-Lines: 62 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:2040 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2040 Richard Stallman writes: > I agree with the people who say this is not very clean: > > The following special call returns t iff a given KEY VALUE > pair is supported on this system: > ! (make-network-process :feature KEY VALUE) > > Couldn't this be done with featurep, using sub-features? > Please try to design it that way. I agree that it would be cleaner (in a purist sense) to have this work through featurep, and technically there is nothing (serious) preventing this from working. 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)) to test whether make-network-process supports datagrams and the local sockets is a lot easier to use (since those are the exact same arguments which are used to select those features) than to test on some similar, but not quite the same, symbols like (if (and (featurep 'networking 'local-sockets) (featurep 'networking 'datagrams)) To take this further, you can test whether a give socket option is supported (without adding extra code at the C-level) with (if (make-network-process :feature :options 'oobinline) whereas doing the same with featurep requires adding more symbols and code to be able to say something like (if (featurep 'networking 'oobinline-option) In fact, what you are asking is that I invent slightly different names for all the various combinations of arguments to make-network-process, just for the purpose of being able to use a standard way to test for the availablility of those features. Actually, if you accept to leave in the :featurep argument, it would be possible to do this at the lisp level using code like this: (let ((subfeatures nil)) (if (make-network-process :featurep :datagram t) (setq subfeatures (cons 'datagrams subfeatures))) (if (make-network-process :featurep :family local) (setq subfeatures (cons 'local-sockets subfeatures))) (if (make-network-process :featurep :options 'oobinline) (setq subfeatures (cons 'oobinline-option subfeatures))) ;; etc... (provide 'networking subfeatures)) -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel