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

Re: Revisiting smart match

Thread Previous | Thread Next
From:
James E Keenan
Date:
December 26, 2017 15:57
Subject:
Re: Revisiting smart match
Message ID:
20171226155727.16560.qmail@lists-nntp.develooper.com
On 12/26/2017 08:29 AM, Leon Timmermans wrote:
> On Mon, Dec 25, 2017 at 4:52 PM, David Golden <xdg@xdg.me 
> <mailto: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

That's an idea that warrants serious investigation!

jimk

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