Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
From: Tom Molesworth via perl5-porters
January 16, 2022 08:12
Re: PSC #049 2022-01-07
Message ID: CAGXhHd=V_qk57r=cbMW+B6P1P4Kj=-yLBjoiGCK1Aik6dvKXww@mail.gmail.com
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
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". 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.
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.