Re: featurep

["Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>]

> > 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