Front page | perl.perl5.porters |
Postings from June 2022
Re: disabling smartmatch and when()?
Thread Previous
|
Thread Next
From:
Tom Molesworth via perl5-porters
Date:
June 25, 2022 12:09
Subject:
Re: disabling smartmatch and when()?
Message ID:
CAGXhHdnoWOSztbJP-0W0mqBodDjYFErcSw=EZJO+2weTwi29+Q@mail.gmail.com
On Fri, 24 Jun 2022 at 22:07, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:
> I'm all for having a better replacement, but I continue to strongly oppose
> the idea that we *need* one to remove the old thing.
>
Do we _need_ to remove smartmatch before that happens? What development is
currently blocked by having it in place? We don't like the way it works,
sure - but in that case why are other frequently-misused constructs such as
`each %hash` still in core?
> I write a lot of Perl, and have since before smartmatch was introduced. I
> never used smartmatch for much. I have banned it from my projects. I have
> seen it largely unused. Nothing it does can't be done some other way
> already, although sometime more verbosely. We don't need a replacement,
> because *we have gotten along fine without using it for 20 years.*
>
A reminder of what was posted earlier in the discussion -
https://www.nntp.perl.org/group/perl.perl5.porters/2022/06/msg264093.html:
> The result of the above is that half of CPAN relies on smartmatch:
>
>
https://grep.cpanauthors.org/search?q=%7E%7E+OR+%22given+%28%22+OR+%22given%28%22
>
> And that is just CPAN, there's certainly a lot of it in darkpan code too.
which makes "largely unused" an over-generous interpretation of the current
situation, at best!
If you need more statistics: over 30% of the PSC have code _right now_ on
CPAN relying on smartmatch. If we can't trust the guiding lights of the
Perl core development team to be using the "right parts" of Perl, what hope
for casual developers?
Put another way, I could write your paragraph replacing "smartmatch" with
something like "Moose", and I'd hope that anyone could instantly recognise
that as a flawed line of thinking: people _are_ actively using these
things, we can see that on CPAN, even if specific individual developers can
safely claim not to be using the feature or affected by its removal.
> A replacement would be nice, if it's good, but it doesn't need to exist
> before we take the old thing out.
>
I would suggest that it does.
We went from "Perl does not have `switch`/`case`, just use `if`", to "Perl
has something better than `switch`/`case`, everyone use that instead", and
now it's back to "just use if, we have no realistic plans for improving
this". Taking this away is likely to trigger a significant amount of extra
work on code that's mostly in maintenance mode or worse, and "we took away
a feature and have no replacement" is something I would read as a red flag
and a sign of accelerating language demise. Perception and trust is a
significant part of this: I see this contributing to a sense of "even the
'new' features aren't something we can trust to be around in future".
A clear deprecation path _and_ non-experimental replacement would be needed
before removing smartmatch: what can the community outside P5P do to help
make this happen?
Thread Previous
|
Thread Next