develooper Front page | perl.perl5.porters | Postings from October 2021

Re: review of perlexperiment, 2021-10

Thread Previous | Thread Next
From:
Dan Book
Date:
October 6, 2021 15:23
Subject:
Re: review of perlexperiment, 2021-10
Message ID:
CABMkAVXBq74bOyPu1iHyvAAZskYV85PVZVYeVRt9O4MexVGSkQ@mail.gmail.com
On Wed, Oct 6, 2021 at 11:13 AM H.Merijn Brand <perl5@tux.freedom.nl> wrote:

> On Sun, 03 Oct 2021 23:51:43 +0200, Tomasz Konojacki <me@xenu.pl> wrote:
>
> > On Sun, 03 Oct 2021 16:41:37 -0400
> > "Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> >
> > > *smartmatch* — We have resisted removing this failure for years, as
> > > we want to replace it with something else.  My take:  we should
> > > just rip this out and later, *maybe*, put something else in. #13173
> > > <https://github.com/Perl/perl5/issues/13173>
> >
> > Back in 2017 we tried replacing smartmatch with "dumbmatch" and in
> > result we made everyone angry and broke half of CPAN:
> >
> >
> http://blogs.perl.org/users/leon_timmermans/2017/12/smartmatch-in-5277.html
> >
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245769.html
> > https://github.com/Perl/perl5/issues/16310
> >
> https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248507.html
> >
> > I don't want that to happen again.
> >
> > Smartmatch is widely used because of two reasons. First of all, it
> > solves an important problem: it provides "switch" and "in" operators.
> > Of course, it does that in a completely insane way, but currently
> > there are no (core) alternatives to it.
>
> I agree on this statement. And my mind is ambiguous.
> As a developer and maintainer of perl I want it gone
> As an (end)user I want it to stay, even in its current state: there is
> no (easy) alternative, and I have a few (huge) scripts that depend on
> it. All of them were converted from insane if/elsif/else trees into
> readable switch structures. I really don't feel thrilled to rewrite
> them again. (all I use is undef/numeric/string/regex, no overloading,
> hashes or arrays).
>

I have a similar position, though I personally have avoided using it
wherever possible. Note for this particular simple case,
https://metacpan.org/pod/Switch::Plain could be a
sufficient replacement, though it doesn't have special undef handling. And
https://metacpan.org/pod/Syntax::Keyword::Match will soon be getting
stabilized and cored. Both of these options only work on 5.14/5.16+ of
course.

The use as an "in" operator is more difficult to replace with current
available options, IMO.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About