develooper Front page | perl.perl5.porters | Postings from June 2016

Re: [perl #128301] [PATCH] Test to see if hash values are eagerlycreated

Thread Previous | Thread Next
From:
Zefram
Date:
June 2, 2016 20:31
Subject:
Re: [perl #128301] [PATCH] Test to see if hash values are eagerlycreated
Message ID:
20160602203117.GA11737@fysh.org
Yves sent a reply directly to me, but has clarified privately that he
intended it to go to the list.  Here it is in full:

>Date: Thu, 2 Jun 2016 16:19:58 +0200
>From: demerphq <demerphq@gmail.com>
>Message-ID: <CANgJU+VCAALbCtxMF5=Y62X-rMvvfYMCZot-8e8-yesDUOqmSw@mail.gmail.com>
>
>On 1 Jun 2016 6:41 p.m., "Zefram" <zefram@fysh.org> wrote:
>>
>> demerphq wrote:
>> >A bug that lives long enough is a feature?
>>
>> A bug that lives long enough may be troublesome to fix.
>
>Heh. Dont I wish i had no idea what you mean!
>
>>In this case
>> I'm satisfied that it's not a bug, it's Larry's design,
>
>If you are satisfied of that then its good enough for me.
>
>>but even if it
>> were clearly buggy it shouldn't be changed accidentally.
>
>Agreed. But there is history of people using tests to justify that a
>particular behaviour is expected when there is no documentation to say
>otherwise.
>
>To me there is a tension between the desire to create tests which tell us
>when something has changed and tests that tell us something is right.
>
>So i am all fine with us 'blindly' enumerating how things work so long as
>we note that the test is not binding on us that it *should* work that way.
>I am also fine when a qualified person (like yourself) does the required
>research to determine that the test corresponds with what we consider to be
>right. But i feel we shouldnt confuse the two types of test intent.
>
>>  The behaviour
>> is readily accessible in ordinary programs, and affects their semantics
>> in obvious ways.  On simple stability grounds, it's worth having test
>> cases to enforce that we don't change this behaviour without specific
>> intent to do so.
>
>Again no arguments there.
>
>> If you want to change it, presumably you wouldn't want to make
>> foo($x{bla}) eager, because that would be creating unintended hash entries
>> all over where the parameter is taken by value.  Presumably you'd want
>> to make \$x{bla} lazy.  I don't have a clear idea of what impact that
>> would have.  Maybe you should do a CPAN smoke of that version of the
>> core (it's a very easy change to make), though obviously changes of
>> the underlying language aren't really what CPAN module test suites are
>> looking for.  Presumably we'd want a deprecation cycle for the change,
>> or a feature flag, and that seems an awful lot of fuss to go to for a
>> design wart of such low wartiness.
>>
>> If all you want is for a lazy version of \$x{bla} to be available, that
>> could be easily implemented by an XS module.  (Alas, "sub lazy_lv {
>> \$_[0] }" doesn't do it: it becomes eager.)
>
>Really i am fine with you saying 'ive reviewed the tests and as far as i
>can tell they all match expected behaviour' i just want to be sure that
>someone does so or otherswise we should note the test as nonbinding.
>
>Fwiw i have encountered this scenario a few times and it is a pain
>Eg two tests that are contradictory but due to bugs both pass. If both are
>binding then we have a problem.
>
>Yves
>Ps writingvthis mail on a phone with my fat fingers was a real pain. Please
>forgive any typos.

-zefram

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