Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
January 16, 2022 08:44
Re: PSC #049 2022-01-07
Message ID: CANgJU+UHmpcpCyiamHM1GUpz8OiKczi4xynr87KJhbmCpUfbGA@mail.gmail.com
On Sun, 16 Jan 2022 at 09:12, Tom Molesworth via perl5-porters <
> There is an important technical and usability point remaining, but I have
> removed Ricardo's address from the CC list to avoid harrassment:
> On Sun, 16 Jan 2022 at 08:43, Ricardo Signes <firstname.lastname@example.org>
>> On Sat, Jan 15, 2022, at 6:02 PM, Yuki Kimoto wrote:
>> Is it possible to include an arity check discussion?
>> The arity check discussion seems to be ignored.
>> *This topic has been discussed numerous times over the last seven years,
>> and I'm not going through it again. This will be my last reply to any
>> message on the topic of changing the strict arity checking of subroutine
> Could we get clarification on whether this is an official PSC decision
> terminating *all* further conversation on the topic, or a personal
> statement of withdrawal from a still-open discussion?
> The linked message does not even attempt to address the point raised in
> the original message in that thread - I'd go as far as to say it exhibits a
> lack of understanding of the point in the first place. I'd further note
> that the thread was started by a PSC member, even after the 7 years of
> previous discussion!
> For reference, original message:
> and as for "discussion seems to be ignored", I agree with this sentiment -
> there was no followup to my offer here:
> To recap the original problem: someone who learns Perl-with-signatures who
> wants to pass a callback to a CPAN module will be writing fragile code.
> This is something that library authors have no control over. The suggestion
> is "library documentation should tell developers that they must always
> include , @ in callbacks".
If those callbacks do not share a common signature then yes, that is what
they must do. I dont understand why you assume that any case where
callbacks are used will have inconsistent signatures. It seems to me that
it is equally likely most callbacks would be the other way around. Eg,
favoring one case or another is an arbitrary decision that comes down to
some external factoid about the situation.
FWIW, I used to have *very* strongly *aligned* views with you about the
warnings coming from sprintf Avar introduced ages back. At first I loathed
that sprintf would warn if I passed in more arguments than it used. But
over time I found that it actually saved me from embarrassment more often
than it hindered my projects. Not exactly your point, but not exactly a
different one either.
> There are no tools or mechanisms offered to enforce this... so people will
> leave it out, and things will work. They will work until a new version of
> that library is released which now passes additional optional parameters:
> then they will break.
Isn't this a question for the implementer of the callback mechanism?
> Providing a way for the library code to deal with that - an explicit
> opt-out for arity checking, *not* a change to the defaults across the rest
> of Perl - seems like a basic courtesy to developers. If we are outright
> rejecting that, I find that disappointing. More so if the given reason is
> "we've been discussing signatures for 7 years already", rather than any
> specific technical impediment.
But doesn't the @ mechanism do that? Eg, if an author of an API that takes
callbacks as a parameter should document that the callback API might change
over time and thus all subs SHOULD have a @ in it?
Is there some introspective approach that would help here? Eg, if I was a
callback author and I could interrogate that the signature did not have a @
as its last clause then I could warn if someone supplied me a callback that
Anyway, I see the problem you are worried about and agree it has merit. But
I'm not sure that the policy approach that rjbs is taking is unreasonable
either. Is there a middle ground that would satisfy?
perl -Mre=debug -e "/just|another|perl|hacker/"