develooper Front page | perl.perl5.porters | Postings from December 2017

Re: Revisiting smart match

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
December 26, 2017 13:29
Subject:
Re: Revisiting smart match
Message ID:
CAHhgV8j8Ls9H1bR8FbDVibv_Axsg+Ws=mLXyD2PoX7mt=Aezag@mail.gmail.com
On Mon, Dec 25, 2017 at 4:52 PM, David Golden <xdg@xdg.me> wrote:

> My 2 cents:
>
> 0.01: I really don't like the proposed keywords and think the bikeshed
> needs more paint.
>
> 0.02: I don't object to removing a feature marked experimental after 5
> years, even if it breaks stuff.
>
> Arguments that "people on old perls will suffer when they upgrade" don't
> carry a lot of weight with me, as that population has already demonstrated
> they don't upgrade often or they'd have seen the warning.  As a volunteer
> driven-and-funded community project, I don't think the Perl core should
> hold itself hostage to distros that ship ancient perls.  (Unlike toolchain
> and high-river CPAN modules, which I think *do* benefit the community with
> a longer support window.)
>
> I think it's generally accepted wisdom now (in several dynamic languages
> communities, not just Perl) that people should run applications using their
> own interpreter, not the system one.  So who suffers if a newer Perl breaks
> stuff?  People who don't follow the wisdom?  They can learn why it's a
> widely used pattern.  Sysadmins who have scripts they want to "just work"
> on newer OSes?  They're sysadmins... I expect them to be able to install
> their own Perl and use it if they need to.  Newbies?  They aren't using
> experimental features anyway.  DarkPAN?  Who knows, they don't tell us, and
> they don't pay for support... but they do pay their own sysadmins who,
> again, can work around these issues and probably aren't going to jump 5+
> years of OSes and Perls without testing anyway.
>
> Five years of warnings not to rely on something is plenty.
>
> I'd also be fine *removing* given/when/smartmatch entirely in the next
> release even if there isn't a replacement.  There's no need to rush the
> replacement if the design is controversial.
>

What if we removed it from core, but left enough hooks so that we can
republish it as a module (let's call it smartmatch::traditional for the
moment). That way users can write code that will work on both previous
versions of perl with the current smartmatching, and future perls that have
extirpated it from core. Better yet this allows the wider community on CPAN
to come up with better smartmatch implementations.

Leon

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