Bug #121680 for Net-DNS: [PATCH] Improve map hash handling

On Sun May 14 13:10:40 2017, RURBAN wrote: Show quoted text
If 'use strict;' means anything at all, it means strict adherence to the language rules as laid down in the scriptures. map BLOCK LIST map EXPR,LIST Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each element) and returns the list value composed of the results of each such evaluation. In scalar context, returns the total number of elements so generated. Evaluates BLOCK or EXPR in list context, so each element of LIST may produce zero, one, or more elements in the returned value. and Map always returns a list, which can be assigned to a hash such that the elements become key/value pairs. See perldata for more details. my %hash = map { get_a_key_for($_) => $_ } @array; Sure, these code fragments can be cleaned up, and will be, but using 'map' in this way is perfectly legitimate. Show quoted text
If there is an entry for $key in the key table, an undefined digest function is logically impossible. If there is not, then this bit of code is unreachable.

Show quoted text
Legitimate in perl5, but not in cperl since 5.27 with use strict. See also http://perl11.org/blog/strict-hashpairs.html map only acts on lists and arrays. hashes only act on list or array pairs. mapping a map list to a hash only makes sense with pairs. multiple pairs or odd lists are too dangerous, hence my new strict mode forbids it. you can decide to close out cperl from your users or add my patches. Show quoted text
I fall into this error, so I had to add it.

Show quoted text
Well, that’s where we disagree :) Show quoted text
Well, from CPAN there are only 6 modules involved. That’s easy to maintain patches for. But in the long run people should use proper practices, i.e. produce a pair in map for hashes. Show quoted text
Well, I decided to allow only a pair, not multiple in strict mode. In non-strict mode it is still valid code. Show quoted text
Well, I moved on some days ago, but when I find it again I will tell you. It probably had to do with rejected strict ‘hashpairs’ map.

Reini Urban rurban@cpan.org Show quoted text
That’s your point of view. My point of view is that cperl is besides perl6-lang and p5p one of the three perl language defining committees. perl6-lang has not much influence on CPAN modules (yet), only p5p and cperl has. p5p has a negative track record in designing features (in fact they failed in all attempts for 15 years), whilst cperl has no negative track record, and pushed 10x more fixes and features in 2 years than p5p in 15 years. p5p is actively destroying the language and the community, cperl is fixing and building it. everybody was waiting for 15 years that perl5 is being fixed. cperl is doing that. See http://perl11.org/blog/p5p-incompetence.html or https://www.reddit.com/r/cperl/comments/4gcwvi/what_to_do_with_p5p/ unilaterally: you mixed that with p5p development style. they unilaterally decide what’s being implemented and how, commit it to master without any discussion and there it is. everything sprout did in the last years. or what nicholas clark on the 10 years before. highlights being the double readonly system, the horrible COW system, and ref instead of bind, despite a good design from perl6, a design for perl5 by chip salzenberg (OP_BIND being reserved for >10 years), which was not pursued because it would slow down every single SV access at run-time. sprout didn’t care and implemented just that, slowing down every single SV access at run-time, and on top of that with an ill-designed \$ref syntax, not the better bind := perl6 syntax. in p5p technical criticism is disallowed and censored via their new religious code of conduct in which all violations by p5p members are tolerated (calling all germans or critics “assholes" being the typical way of engagement with the community), and technical criticism from outside is a violation for their new “lack of faith” argument. in cperl a feature is first publicly designed and presented as issue, then smoked in a branch, then smoked on cpan, and only then merged to master and released. like in perl6 and unlike in perl5. additionally to github cperl allows uncensored discussion in /r/cperl on reddit. /r/perl, blogs perl and p5p is censored by p5p shills and trolls with hilarious arguments. everybody who rather engages in p5p discussions about perl5 features is helpless, as these discussions are censored, meaningless, and actually harmful. they are actively leading to the destruction of perl5. you should rather engage yourself in perl6 and cperl feature discussions if you want to influence future changes. well defined: if it was well defined it wouldn’t lead to trouble. in fact it is ill defined, so I fixed it. this is one of the few features not taken from perl6. Show quoted text
I never said that. I gave you a fix for cperl. It would be your fault not to apply it and leave out cperl support. it would raise the bar for cperl users. In order to fix dangerous habits such fixes are necessary. perl5 is not going anywhere, is badly maintained, is losing all it’s users, and is a security risk to use on public services. it’s still in the top 10 with lots of legacy code, cperl is recommended to be used there. p5p doesn’t take any cperl fixes, dozens of high risk fixes are live, and it get’s worse and worse every year. I’ve publicly warned from using perl5 since 5.16, and personally fixed all the known issues. and cperl broke only one feature (-d with sigs), whilst perl5 broke many more (binary names, cow, lexical $_, use encoding, types, the bytecode compiler). Show quoted text
no, as explained it makes it clear that a list is spliced into a hash. splicing a map into a hash demands pairs. the strict hashpairs name is it clear enough. 'use strict; my %hash = @{[map {$_} (0..1)]}' is a valid single line alternative, but cperl does not recommend such code golfing. hence i left it unmentioned.