develooper Front page | perl.perl5.porters | Postings from July 2019

Re: [perl #133809] Perl silently adds a key to hash

Thread Previous | Thread Next
From:
demerphq
Date:
July 13, 2019 21:04
Subject:
Re: [perl #133809] Perl silently adds a key to hash
Message ID:
CANgJU+WWKUuS7D=uXNzvBaNYGufT4B28q4_HZ-Ava6R=9XJ3YA@mail.gmail.com
On Sat, 13 Jul 2019, 19:42 Deven T. Corzine, <deven@ties.org> wrote:

> On Sat, Jul 13, 2019 at 8:00 AM demerphq <demerphq@gmail.com> wrote:
>
>> On Sat, 13 Jul 2019, 13:40 Leon Timmermans, <fawaka@gmail.com> wrote:
>>
>>> On Sat, Jul 13, 2019 at 12:46 PM demerphq <demerphq@gmail.com> wrote:
>>> >
>>> > It's the right thing because Larry said it was the right thing. Our
>>> community depends on this understanding. And we really try to avoid debates
>>> like this, Larry made a decision decades ago, and it's not subject to
>>> review or change.
>>>
>>
>> I was speaking to a specific exchange which I believe is still covered by
>> rule 1.
>>
>> Arguing that it's not the right decision is imo unhealthy for our
>> community, arguing that regardless we should support something else as well
>> isn't.
>>
>
> I wasn't aware of Larry making a Rule 1 call about this behavior -- I'm
> sorry if I've disputed such a call, that certainly wasn't my intent.  To be
> clear, I was NOT arguing that the current behavior is wrong.  It's easier
> to implement, reasonable, logical, and certainly justifiable as the "right"
> behavior, at least from an implementation perspective.
>
> From another perspective -- the Perl programmer's DWIM perspective --
> avoiding unnecessary autovivification for "read-only" usages would be (IMO)
> more intuitive behavior which more likely matches the programmers intent,
> and therefore might reasonably be viewed as "the right thing" from that
> programmer's perspective.
>
> The point I was trying to make was that describing this behavior as "the
> exact right thing" is a bit over the top, particularly because the
> inclusion of "exact" in that phrase implies that this is the only
> reasonable "right" behavior and anyone who believes otherwise is ignorant
> or misguided.  My objection was only about this phrasing in "perlreftut",
> not the original decision itself.
>
> Rule 1 stoped being a useful rule when we lost rule 2.
>>>
>>> I do think it's possible to make this change. I very much think the
>>> behavior that is being proposed is more intuitive (and tellingly I
>>> haven't seen anyone argue otherwise). IMO there are three questions
>>> that are relevant for deciding whether we should do this.
>>>
>>> * What will break?
>>>
>>
>> Who knows? I have seen code that exploits this behaviour. But there is no
>> way to know until we try it. Doesn't seem to me to be something we can
>> change without a pragma.
>>
>
> Would you mind expanding on this, if you remember any details?  I'm having
> trouble even imagining a hypothetical situation where the Perl programmer
> would prefer unnecessary autovivification, so I'd love to hear more about
> how and why someone wanted to exploit this behavior.
>
>
>> * What does it cost us in complexity?
>>>
>>
>> I doubt that much.
>>
>> * What does it cost us in performance?
>>>
>>
>> I doubt that much.
>>
>> None of those questions (or their answers) involve invoking Larry.
>>>
>>
>> Agreed, but it's a different discussion than the one I responded to.
>>
>> Yves
>>
>
> 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.

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

>
>

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