Front page | perl.perl5.porters |
Postings from July 2019
On Sat, Jul 13, 2019 at 5:03 PM demerphq <demerphq@gmail.com> wrote: > On Sat, 13 Jul 2019, 19:42 Deven T. Corzine, <deven@ties.org> wrote: > >> I'm sorry, I didn't mean to cause any drama or dispute any decisions by >> Larry under Rule 1. My bad. >> >> I would love to have the other discussion about whether the current >> behavior could be changed (perhaps with a pragma) to avoid autovivification >> except when actually required to store new data. I do believe that most >> Perl programmers would consider that more intuitive. (Leon has a good >> point that nobody is arguing otherwise!) >> >> I suspect that many Perl programmers would appreciate such a change, >> since code often needs to be added solely to prevent unwanted "read-only" >> autovivification.. >> > > > I don't think we can change the default behaviour, on the other hand I > think core should own 'no autovivification' and make it as efficient as > possible. > Would it be so bad, to change the default behavior -- perhaps with a deprecation cycle? It's not like Perl releases *never* break existing code. Here's a post from just last month about Perl 5.30 breaking existing code due to deprecation of my() in false conditionals: https://dev.to/mitchjacksontech/perl-5-30-deprecates-use-of-my-in-a-false-conditional-55bg Actually, I wonder if changing the autovivification behavior might actually FIX more code than it breaks! (It's plausible, I think...) As for the "autovivification" pragma being in core, I think that's a great idea. > My original comment was about *how" you make this argument, I actually > agree with your underlying premise and I very much appreciate how you > responded to my mail. Our rules are about creating a functional community > not about squelching people's opinion. > > Cheers, > Yves > I'm all for maintaining a functional community. There's already enough drama, no need for more! DevenThread Previous | Thread Next