develooper Front page | perl.perl5.porters | Postings from November 2020

Re: Looking for someone to adopt adding trim() to core

Thread Previous | Thread Next
From:
demerphq
Date:
November 11, 2020 18:00
Subject:
Re: Looking for someone to adopt adding trim() to core
Message ID:
CANgJU+V1DWSEPndLAC=gswPiAcz4V_CTe-SXksNwqM_w01cgsw@mail.gmail.com
On Wed, 11 Nov 2020 at 17:47, Dan Book <grinnz@gmail.com> wrote:
>
> On Wed, Nov 11, 2020 at 10:02 AM demerphq <demerphq@gmail.com> wrote:
>>
>> Why does it need to be added to the language as a new keyword? You
>> could add it via universal.c to the SCALAR namespace (for example) and
>> have it accessible without any feature horribleness. I believe we have
>> already approved that such namespaces are acceptable. And additions to
>> them do not need any feature bodge and are trivially made backwards
>> compatible.
>>
>> print SCALAR::trim($str);
>>
>> I vote "no" to this as a feature. But I am fine with it being in core
>> via universal.c and the right namespace.
>
>
> This is completely unlike any other language feature and means that code will forever have to write it this way. I prefer adding it as a feature.

On the contrary, this is how it was done before the  feature concept
existed, see especially the utf8 namespace but we also have done it in
the 're' namespace as well, along with the Internals namespace,
constant namespace, and Tie::Hash::NamedCapture actually. Arguably we
use features for things we shouldn't. If it doesn't need to change
perls parser it shouldn't be a feature. Anything that can be handled
as a namespaced sub should be. That is what symbol imports are for.

I would argue that  the feature interface should ONLY be used when the
features introduces a change that could NOT be backported to an old
perl via a normal module/XS implementation. I think it is an abuse and
back compatibility liability when it is used for a mere function.

Also we actually had an agreement about a year ago that we would
"define" Scalar/Array/Hash as the "canonical" namespaces for functions
like this, precisely because it would then allow us to backport these
new keywords.

IMO if we are not going to add "reftype" to the language as a keyword
that we sure as heck shouldnt add trim. Again, that is what modules
are for. Having them as namespaced built ins (so they can be back
ported) seems a reasonable compromise.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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