Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

defined on HashofHash defines an element in the hash #15231

Closed
p5pRT opened this issue Mar 14, 2016 · 20 comments
Closed

defined on HashofHash defines an element in the hash #15231

p5pRT opened this issue Mar 14, 2016 · 20 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 14, 2016

Migrated from rt.perl.org#127712 (status was 'resolved')

Searchable as RT127712$

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From phberninger@gmx.net

Checking with defined for an Hash of Hash element defines the element in the hash, instead of returning undefined​:

The following code will reproduce it​:

 

perl -e 'if(defined($foo{"a"}{"b"})){ print "not defined\n";}if(defined($foo{"a"})){ print "ERROR? now defined?\n";}   '

 

I hope it is not a feature. tested with perl 5.20.2 under Linux

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @tonycoz

On Mon Mar 14 09​:45​:35 2016, phberninger@​gmx.net wrote​:

Checking with defined for an Hash of Hash element defines the element
in the
hash, instead of returning undefined​:The following code will reproduce
it​: perl
-e 'if(defined($foo{"a"}{"b"})){ print "not
defined\n";}if(defined($foo{"a"})){
print "ERROR? now defined?\n";} ' I hope it is not a feature. tested
with perl
5.20.2 under Linux

This is a known problem[1], and is difficult to fix because the change would break existing code.

You can avoid this behaviour by using the autovivication module from CPAN.

Tony

[1] that autovivication doesn't always respect lvalue vs rvalue

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @jkeenan

On Mon Mar 14 09​:45​:35 2016, phberninger@​gmx.net wrote​:

Checking with defined for an Hash of Hash element defines the element
in the
hash, instead of returning undefined​:The following code will reproduce
it​: perl
-e 'if(defined($foo{"a"}{"b"})){ print "not
defined\n";}if(defined($foo{"a"})){
print "ERROR? now defined?\n";} ' I hope it is not a feature. tested
with perl
5.20.2 under Linux

I do not believe this is a bug.

The test for definedness of $foo{a}{b} in the first 'if' block autovivifies $foo{a},

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @jkeenan

On Mon Mar 14 15​:36​:44 2016, jkeenan wrote​:

On Mon Mar 14 09​:45​:35 2016, phberninger@​gmx.net wrote​:

Checking with defined for an Hash of Hash element defines the element
in the
hash, instead of returning undefined​:The following code will
reproduce
it​: perl
-e 'if(defined($foo{"a"}{"b"})){ print "not
defined\n";}if(defined($foo{"a"})){
print "ERROR? now defined?\n";} ' I hope it is not a feature. tested
with perl
5.20.2 under Linux

I do not believe this is a bug.

The test for definedness of $foo{a}{b} in the first 'if' block
autovivifies $foo{a},

That post was incomplete. See attached.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Mar 14, 2016

From @jkeenan

127712-defined.pl

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2016

From @pjcj

On Mon, Mar 14, 2016 at 03​:31​:02PM -0700, Tony Cook via RT wrote​:

On Mon Mar 14 09​:45​:35 2016, phberninger@​gmx.net wrote​:

Checking with defined for an Hash of Hash element defines the element
in the
hash, instead of returning undefined​:The following code will reproduce
it​: perl
-e 'if(defined($foo{"a"}{"b"})){ print "not
defined\n";}if(defined($foo{"a"})){
print "ERROR? now defined?\n";} ' I hope it is not a feature. tested
with perl
5.20.2 under Linux

This is a known problem[1], and is difficult to fix because the change would break existing code.

Break, in the sense of altering. But this is the case for all bug
fixes. Since the last century the following has appeared in perlfunc​:

  This surprising autovivification in what does not at first--or even
  second--glance appear to be an lvalue context may be fixed in a future
  release.

Now, this bug has existed for a long time and therefore is in a slightly
different category to a bug in a new feature, for example, which gets
fixed a release or two later. But are we seriously saying that we
cannot fix this now because, we assume, too much code would change
behaviour?

If that is the case, then the documentation should be updated to reflect
this policy. If not, Tony makes it sound as though it is otherwise not
difficult to fix. That was not my understanding, but if it is so, then
should we not fix it?

If we would still like to fix it but cannot at the moment, for some
other reason, then things stay as they are.

Which case do we have here?

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

@p5pRT
Copy link
Author

p5pRT commented Mar 15, 2016

From zefram@fysh.org

Paul Johnson wrote​:

                              are we seriously saying that we

cannot fix this now because, we assume, too much code would change
behaviour?

If that is the case, then the documentation should be updated to reflect
this policy.

Yes, we should document that the (default) autovivification behaviour
won't change.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Mar 16, 2016

From @epa

Another possibility is to control the autovivification behaviour with
'use 5.24' and so on.

--
Ed Avis <eda@​waniasset.com>

@p5pRT
Copy link
Author

p5pRT commented Mar 16, 2016

From zefram@fysh.org

Ed Avis wrote​:

Another possibility is to control the autovivification behaviour with
'use 5.24' and so on.

Absolutely. There is a prototype of this on CPAN, autovivification.pm,
and this kind of effect seems a good candidate to be incorporated into the
core. It'd have to have an independently-settable pragmatic flag, which
can then be incorporated into one of the perl-version feature bundles.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From @jkeenan

On Tue Mar 15 12​:31​:27 2016, zefram@​fysh.org wrote​:

Paul Johnson wrote​:

                              are we seriously saying that we

cannot fix this now because, we assume, too much code would change
behaviour?

If that is the case, then the documentation should be updated to reflect
this policy.

Yes, we should document that the (default) autovivification behaviour
won't change.

-zefram

Paul, zefram, et. al.​:

Could someone propose some wording for this documentation clarification? That would help move this ticket toward closing.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From zefram@fysh.org

James E Keenan via RT wrote​:

Could someone propose some wording for this documentation clarification?

In perlfunc.pod, section on "exists", delete the paragraph

  This surprising autovivification in what does not at first--or even
  second--glance appear to be an lvalue context may be fixed in a future
  release.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From @pjcj

On Thu, Apr 21, 2016 at 03​:47​:25AM +0100, Zefram wrote​:

James E Keenan via RT wrote​:

Could someone propose some wording for this documentation clarification?

In perlfunc.pod, section on "exists", delete the paragraph

This surprising autovivification in what does not at first\-\-or even
second\-\-glance appear to be an lvalue context may be fixed in a future
release\.

It is disappointing that this language wart seems to be here to stay.
Is there any way that it could be fixed under "use feature" or "use
5.26" for example? Can anyone think of a good solution here?

If not then yes, just deleting the caveat from the docs seems
appropriate.

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From zefram@fysh.org

Paul Johnson wrote​:

Is there any way that it could be fixed under "use feature" or "use
5.26" for example?

Yes. A feature flag would be a fine way to switch to different
autovivification semantics, and it could go into a version bundle.
Patches welcome.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From @pjcj

On Thu, Apr 21, 2016 at 12​:18​:41PM +0100, Zefram wrote​:

Paul Johnson wrote​:

Is there any way that it could be fixed under "use feature" or "use
5.26" for example?

Yes. A feature flag would be a fine way to switch to different
autovivification semantics, and it could go into a version bundle.
Patches welcome.

In which case, perhaps, deleting the caveat from the documentation may
be somewhat premature.

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

@p5pRT
Copy link
Author

p5pRT commented Apr 21, 2016

From zefram@fysh.org

Paul Johnson wrote​:

In which case, perhaps, deleting the caveat from the documentation may
be somewhat premature.

The caveat is warning about possible changes in behaviour of existing
code, and we're ruling that out. If we were to have anything in the
documentation referring to the possible future feature flag, it would
need different wording, and ought to be relocated to perlref(1). But for
the most part we don't sprinkle our wishlist throughout the documentation.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

From zefram@fysh.org

Documentation updated in commit d3f0c81.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 5, 2017

@cpansprout - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant