Re: featurep

[Stefan Monnier]

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