Re: featurep

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> > address@hidden (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 <address@hidden> http://www.cua.dk