Front page | perl.perl5.porters |
Postings from February 2021
On Mon, Feb 15 2021, demerphq wrote:
Hi. Long time!
This E-Mail isn't really a rebuttal of anything.
Just things I noticed in skimming this thread that seem to not have been
pointed out.
Disclaimer: I don't care much either way about this version of trim()
being in core and if so how it's implemented.
> On Mon, 15 Feb 2021 at 10:30, Christian Walde <walde.christian@gmail.com> wrote:
> [...]
> I will restate my position: we should not add any new keywords to perl
> that do not have an "undef" prototype. That is we should not add any
> new keywords to the language that can be expressed as a normal
> function. Note this specially allows adding new control keywords,
> which includes operators.
1.
I'm inclined to agree, but I think you're entirely focusing on backwards
compatibility wrt. feature.pm in terms of whether you can write a
function in pure-Perl that replaces the proposed feature.
Another attribute of implementing things via feature.pm is that you can
lexically phase-in parts of your code to use the feature:
$ perl -e 'sub say { print "whee: ", @_, "\n" } { use feature qw(say); say "hi" } say("there")'
hi
whee: there
So if we're imagining cases where we're stepping on existing in-the-wild
trim() functions having things implemented via features allows you to
lexically phase-in parts of your code in a way that's not practically
possible if you do the same with glob assignments.
Are there really people with existing "use Text::Trim qw(trim)" code at
the top of a package who would like to phase-in to CORE::trim() a scope
at a time? Probably not.
But it's not *just* about prototype($func) = undef, just say'n.
2.
Am I the only one who finds it jarring to have a trim() that's very
similar to chop() and chomp() in the language that has a completely
different calling convention?
Evidently, from the lack of discussion about it.
I'm aware that chomp() is a frequently mentioned point of suckyness
about Perl, but I actually quite like being able to do this without a
for-loop:
chomp(my @clean = lines());
And in terms of speed being able to munge a SV inline helps.
Also, it has an undef prototype, so if you're one of the people who
wants this, and that's demerphq sticking point. Just saying.
You could even make it also behave like the currently proposed trim()
function with wantarray.
I think chomp-ing a list is very useful, I've done that thousands of
times. I don't think I've ever written anything to use chomp's return
value.
> [...]The new keyword thing however has no legs and I expect that it
> will continue to be rejected for the reasons I have stated in this
> mail.
My reading of this back and forth is that it's not really about the
implementation details of whether it's a feature or not.
Rather, I think there's people who'd like to eventually get to the point
of just calling "trim()" in a one-liner just like they use "say" now:
perl -E 'say trim shift'
I sympathize with that, and for that it wouldn't really matter if it's a
keyword or something injected into *main::trim by universal.c, but
anything past that would make it an uglier duckling than using the other
built-in string functions.
Thread Previous
|
Thread Next