Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: syntax for quote-words-arrayref
Thread Previous
|
Thread Next
From:
Neil Bowers
Date:
June 1, 2022 09:44
Subject:
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
beab4f58-18e3-47e8-9cd5-572c9c7727a1@Spark
Hi Garu!
> I like the idea of reviewing idioms and updating operators, but does the proposed new operator add enough value to the language to be included? It is adding 1 extra quote-like operator for a 2-character gain (only 1 if qwa is used instead of qa) and maybe a little extra readability
A good question to ask. I mentally think of this as a single construct, but I have to use two constructs to write it. Given itâs so widely used, I think itâs worth providing its own construct.
> is code really that more clear/legible as qa[...] than it is with [ qw(...) ]?
In short, yes :-)
I remember that the first N times I saw [qw/ ⦠/] I initially had a "huh, wtf is that?". I think it is more of an improvement for beginners and casual Perl programmers, than for heavyweights, who may still use the existing idiom even with qa[] available, due to muscle memory.
> will qa() or qa|| or qa// etc be allowed?
Yes, I think it would, but by convention Iâd expect almost everyone to use qa[].
If we went the qs[] route instead, then I think the bracketing characters should be restricted.
> I probably have a lot of code using the [ qw( a b c ) ] idiom, but I honestly don't see myself using qa[] just to replace that idiom. Maybe it's one of those things you only see the value once it's there, or maybe I'm just lazy :)
I donât feel qualified to comment on your laziness, but (a) Iâve a friend I could ask ;-), and (b) see https://www.goodreads.com/en/book/show/54304124-laziness-does-not-exist
>> But, you say, what if people want the literal '@defaults' in there?
>> I think things that are different should look different,
>> and if you want that literally, then you should see '@defaults'.
> That's a lot of edge cases to consider and way too deviant from current quote-like operators' behaviour.
> I think it would cause more confusion than benefits, like people trying to do the same with qw().
> Especially when you already can achieve similar behaviour with just a few characters more.
Ah. Re-reading what I wrote, maybe you thought I was saying that you should be able to quote things inside qa[]?
Thatâs not what I was trying to say. I meant that if you want to quote things (e.g. due to spaces), then donât use the qa[] operator at all.
   my $ref = ["thing with spaces", qw/ one two three /];
> Also, what if you don't want to interpolate? It could soon follow the need for a qqs[] interpolating variables while a qs[] would return a literal '$defaults'. Unless it was already implemented that way, in which case the proper behaviour might need to be puzzled out.
I think that if you donât want interpolation, then you donât use qs.
The benefit is not really about fewer characters, but about clarity. I would use qa[] and qs[] if we went that way. But I donât really like
   my $href = qs{  a x  b y  c z };
because youâve lost the visual hint of => that itâs a hash. It looks like a list. So weâd have to consider allowing => as a no-op, which also feels yucky.
qs is a lot more complex than qa to implement and maintain, and though some people seem to like the idea of interpolation and comments, I donât see the evidence supporting it, which I do for qa. And if we add qa first, even if people love it and then say then want qs as well, already having qa reduces the value of a subsequent qs.
Neil
Thread Previous
|
Thread Next