[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Arbitrary function: find the number(s) of expected arguments
From: |
Drew Adams |
Subject: |
RE: Arbitrary function: find the number(s) of expected arguments |
Date: |
Fri, 25 Mar 2016 11:31:56 -0700 (PDT) |
> > > `subr-arity' is still in the documentation, but I replaced its
> > > description with an advice to use `func-arity' instead.
> >
> > Again, that is wrong, IMO.
>
> It isn't.
It is, IMO.
> > IIUC, you _cannot_ use `func-arity' to test whether something
> > is a subr.
>
> You have subrp for that; using subr-arity for this purpose borders
> on the ridiculous. It's certainly unclean.
Doesn't matter. The doc string of `subr-arity' should be faithful
to what it does. Unless we deprecate it in favor of `func-arity',
it is incorrect to pretend that the doc for `func-arity' describes
the behavior of `subr-arity'.
I never said that one should use `subr-arity' in place of `subrp'.
I said only that `func-arity' does not give you the behavior of
`subr-arity'. The doc for the latter should say what it does.
> > IOW, I am repeating the same argument I made before, when
> > I said that `subr-arity' should not be deprecated and
> > simply replaced by `func-arity'.
>
> You were wrong then, and you are wrong now.
You were wrong then, and you are wrong now. Naahhh.
Deprecate `subr-arity' and there will be no problem with having
the doc string of `subr-arity' just send users to the doc of
`func-arity'.
In that case, the only concern is breaking existing code, but
that is often the case when deprecating something. Just
deprecate it - no problem.
> > If my argument is being rejected (in effect - in the new doc
> > string) then why are we not doing that openly (deprecating
> > `subr-arity' and replacing it with `func-arity')?
>
> Because you objected, and I'd rather not start yet another
> endless discussion.
No, I did _not_ object to deprecating it. I only pointed out
that you were wrong in saying that by aliasing you would be
providing backward compatibility. This is what I said:
Ignoring all the rest...
(NB that part. I pointed to a problem with _one_ thing you said.)
This sounds wrong to me. Just calling the new code (which I
have not looked at, but which I presume does for arbitrary
functions what `subr-arity' does for primitives) would NOT
provide backward compatibility, precisely because it would
(presumably) NOT have the same behavior as `subr-arity' for
non-primitives - it would not raise an error.
And that is the case. Just aliasing to `func-arity' would NOT
provide backward compatibility. Nothing wrong with deprecating
`subr-arity'. What was wrong was your claim that aliasing will
provide backward compatibility.
- Re: Arbitrary function: find the number(s) of expected arguments, (continued)
- Re: Arbitrary function: find the number(s) of expected arguments, Paul Pogonyshev, 2016/03/25
- RE: Arbitrary function: find the number(s) of expected arguments, Drew Adams, 2016/03/25
- Re: Arbitrary function: find the number(s) of expected arguments, Paul Pogonyshev, 2016/03/25
- RE: Arbitrary function: find the number(s) of expected arguments, Drew Adams, 2016/03/25
- Re: Arbitrary function: find the number(s) of expected arguments, Clément Pit--Claudel, 2016/03/25
- Use plain-text for mail [was: Arbitrary function: find the number(s) of expected arguments], Drew Adams, 2016/03/25
- Re: Use plain-text for mail [, Lars Magne Ingebrigtsen, 2016/03/25
- Re: Use plain-text for mail [, Andreas Schwab, 2016/03/25
- Re: Use plain-text for mail [was: Arbitrary function: find the number(s) of expected arguments], Yuri Khan, 2016/03/25
- Re: Arbitrary function: find the number(s) of expected arguments, Eli Zaretskii, 2016/03/25
- RE: Arbitrary function: find the number(s) of expected arguments,
Drew Adams <=
- Re: Arbitrary function: find the number(s) of expected arguments, Eli Zaretskii, 2016/03/26
- Re: Arbitrary function: find the number(s) of expected arguments, Paul Pogonyshev, 2016/03/26
Re: Arbitrary function: find the number(s) of expected arguments, Stefan Monnier, 2016/03/15