* Re: featurep [not found] <200203190844.g2J8iOq09224@wijiji.santafe.edu> @ 2002-03-19 13:39 ` Kim F. Storm 2002-03-19 19:24 ` featurep Jason Rumney 0 siblings, 1 reply; 15+ messages in thread From: Kim F. Storm @ 2002-03-19 13:39 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> 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 <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 13:39 ` featurep Kim F. Storm @ 2002-03-19 19:24 ` Jason Rumney 2002-03-19 21:20 ` featurep Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jason Rumney @ 2002-03-19 19:24 UTC (permalink / raw) Cc: rms, emacs-devel 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. -- Jason Rumney _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 19:24 ` featurep Jason Rumney @ 2002-03-19 21:20 ` Stefan Monnier 2002-03-19 23:09 ` featurep Kim F. Storm 2002-03-19 22:59 ` featurep Kim F. Storm 2002-03-21 9:04 ` featurep Richard Stallman 2 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2002-03-19 21:20 UTC (permalink / raw) Cc: Kim F. Storm, rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 21:20 ` featurep Stefan Monnier @ 2002-03-19 23:09 ` Kim F. Storm 2002-03-19 23:19 ` featurep Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Kim F. Storm @ 2002-03-19 23:09 UTC (permalink / raw) Cc: Jason Rumney, rms, emacs-devel "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes: > > 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. I think this would be overkill. If we go that route, then it should apply to all functions - and that has never been the intention. > > 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? In any case, I disagree, but I don't want to be religious about this, so I'll change the code to use featurep. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 23:09 ` featurep Kim F. Storm @ 2002-03-19 23:19 ` Stefan Monnier 2002-03-19 23:48 ` featurep Kim F. Storm 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2002-03-19 23:19 UTC (permalink / raw) Cc: Stefan Monnier, Jason Rumney, rms, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 23:19 ` featurep Stefan Monnier @ 2002-03-19 23:48 ` Kim F. Storm 2002-03-20 0:03 ` featurep Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Kim F. Storm @ 2002-03-19 23:48 UTC (permalink / raw) Cc: Jason Rumney, rms, emacs-devel "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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 <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 23:48 ` featurep Kim F. Storm @ 2002-03-20 0:03 ` Stefan Monnier 0 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2002-03-20 0:03 UTC (permalink / raw) Cc: Stefan Monnier, Jason Rumney, rms, emacs-devel > "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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. That's perfectly fine. I never actually suggested to rely on a `nil' return value. I definitely prefer signalling an error, just make sure that you use a signal that makes the problem clear like `unsupported-network-feature' so that the signal handler can distinguish it from other problems. Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 19:24 ` featurep Jason Rumney 2002-03-19 21:20 ` featurep Stefan Monnier @ 2002-03-19 22:59 ` Kim F. Storm 2002-03-21 9:04 ` featurep Richard Stallman 2 siblings, 0 replies; 15+ messages in thread From: Kim F. Storm @ 2002-03-19 22:59 UTC (permalink / raw) Cc: rms, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > 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. Not but there are fewer things (almost none in fact) to document. Compare (if (make-network-process :feature :family 'local) (make-network-process ... ... :family 'local ...)) to (if (featurep 'networking 'local-sockets) (make-network-process ... ... :family 'local ...)) That's two different pairs of symbols rather than one and the same. But I seem to be out-numbered here, so I'll make the change. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-19 19:24 ` featurep Jason Rumney 2002-03-19 21:20 ` featurep Stefan Monnier 2002-03-19 22:59 ` featurep Kim F. Storm @ 2002-03-21 9:04 ` Richard Stallman 2002-03-21 13:12 ` featurep Kim F. Storm 2002-03-21 16:44 ` featurep Stefan Monnier 2 siblings, 2 replies; 15+ messages in thread From: Richard Stallman @ 2002-03-21 9:04 UTC (permalink / raw) Cc: storm, emacs-devel 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). _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-21 9:04 ` featurep Richard Stallman @ 2002-03-21 13:12 ` Kim F. Storm 2002-03-23 2:35 ` featurep Richard Stallman 2002-03-21 16:44 ` featurep Stefan Monnier 1 sibling, 1 reply; 15+ messages in thread From: Kim F. Storm @ 2002-03-21 13:12 UTC (permalink / raw) Cc: jasonr, emacs-devel Richard Stallman <rms@gnu.org> writes: > 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). Good idea. I've done that! Using featurep has the added bonus of being able to test for networking support in general with (featurep 'make-network-process). You can use (get 'make-network-process 'subfeatures) to get a list of all supported (non-standard) networking features. I'm don't know whether this is an officially supported way to access subfeatures (?), but it allows us to enhance e.g. report-emacs-bug to include the list of supported networking features if you think that might be interesting. I didn't include all the standard features, so while (featurep 'make-network-process '(:family local)) returns t iff local sockets are supported, testing with (featurep 'make-network-process '(:family nil)) returns nil, because the default is always supported, so there is no reason to (be able to) test for it. Is that ok? BTW, I've changed Ffeaturep to use Fmember instead of Fmemq to compare features, so we can now use all sorts of data (e.g. lists or strings) as subfeatures. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-21 13:12 ` featurep Kim F. Storm @ 2002-03-23 2:35 ` Richard Stallman 0 siblings, 0 replies; 15+ messages in thread From: Richard Stallman @ 2002-03-23 2:35 UTC (permalink / raw) Cc: jasonr, emacs-devel I didn't include all the standard features, so while (featurep 'make-network-process '(:family local)) returns t iff local sockets are supported, testing with (featurep 'make-network-process '(:family nil)) returns nil, because the default is always supported, so there is no reason to (be able to) test for it. Is that ok? That seems reasonable. BTW, I've changed Ffeaturep to use Fmember instead of Fmemq to compare features, so we can now use all sorts of data (e.g. lists or strings) as subfeatures. Yes, that was essential here. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-21 9:04 ` featurep Richard Stallman 2002-03-21 13:12 ` featurep Kim F. Storm @ 2002-03-21 16:44 ` Stefan Monnier 2002-03-21 19:47 ` featurep Kim F. Storm 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2002-03-21 16:44 UTC (permalink / raw) Cc: jasonr, storm, emacs-devel > 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. Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-21 16:44 ` featurep Stefan Monnier @ 2002-03-21 19:47 ` Kim F. Storm 2002-03-22 0:39 ` featurep Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Kim F. Storm @ 2002-03-21 19:47 UTC (permalink / raw) Cc: emacs-devel "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes: > > 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. ++kfs _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-21 19:47 ` featurep Kim F. Storm @ 2002-03-22 0:39 ` Stefan Monnier 2002-03-22 9:14 ` featurep Kim F. Storm 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2002-03-22 0:39 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel > > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: featurep 2002-03-22 0:39 ` featurep Stefan Monnier @ 2002-03-22 9:14 ` Kim F. Storm 0 siblings, 0 replies; 15+ messages in thread From: Kim F. Storm @ 2002-03-22 9:14 UTC (permalink / raw) Cc: emacs-devel "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes: > 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. I've already changed the code to use featurep as people on this list requested. It is clean, it is working, and some users may find it useful. So, please, can we stop this discussion, and get on to other work? -- Kim F. Storm <storm@cua.dk> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-03-23 2:35 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <200203190844.g2J8iOq09224@wijiji.santafe.edu> 2002-03-19 13:39 ` featurep Kim F. Storm 2002-03-19 19:24 ` featurep Jason Rumney 2002-03-19 21:20 ` featurep Stefan Monnier 2002-03-19 23:09 ` featurep Kim F. Storm 2002-03-19 23:19 ` featurep Stefan Monnier 2002-03-19 23:48 ` featurep Kim F. Storm 2002-03-20 0:03 ` featurep Stefan Monnier 2002-03-19 22:59 ` featurep Kim F. Storm 2002-03-21 9:04 ` featurep Richard Stallman 2002-03-21 13:12 ` featurep Kim F. Storm 2002-03-23 2:35 ` featurep Richard Stallman 2002-03-21 16:44 ` featurep Stefan Monnier 2002-03-21 19:47 ` featurep Kim F. Storm 2002-03-22 0:39 ` featurep Stefan Monnier 2002-03-22 9:14 ` featurep Kim F. Storm
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.