Re^2: Defined test creates non-empty hash value

Thanks for that. Have understood autovivification of variables when in assignment, increment, etc. but not realized it could affect a test. Googling on autovivification, I found in 'Perl Maven' blog, https://perlmaven.com/autovivification an example, with

"This is quite unfortunate. This means we have changed the state of the %people has just by observing it. ... I think these undesirable cases are now generally considered to be a bug in Perl. Unfortunately it is very unlikely that this bug will be fixed in Perl 5 as there is a lot of code out in the wild (both on CPAN and in companies) that rely on this behavior. Correcting the behavior would break a lot of code."

In the event, I am now wiser. Unfortunately, when creating some sparse hashs of arrays I do rely upon autovivification, with tests to identify their non-existence when necessary. But will now know how to adapt ...

Comment on Re^2: Defined test creates non-empty hash value

Replies are listed 'Best First'.
Re^3: Defined test creates non-empty hash value by cavac (Prior) on Jun 13, 2024 at 10:00 UTC
Yes, this is one of those baked in historical oddities like every mature system has. You know, ones that, when you ask the original designer, the answer always starts with "It made sense at that time..." Those decisions might come back and bite you. But that doesn't mean the original designers made the wrong choice per se, they might just not have been able to see the whole picture that would result many years after they made their choices. Think of the Apollo 1 fire. It made sense for NASA to use a pure oxygen atmosphere in their capsules. It saved a lot of weight (weight is everything in rocketry) AND it made the capsules actually safer (no risk of accidentaly putting too much nitrogen in due to a bad sensor, suffocating the astronauts). It made sense to pressurize the capsules on the launch pad to test that they are not leaking away the precious air in space (reducing the risk of a Soyuz 11 catastrophe). It made sense to place Velcro strips all over the spacecraft interior to prevent objects floating around and messing up other systems (after all, in space under the normal, low O2 pressure, Velcro doesn't sustain fire). What nearly nobody realised were the consequences of the combination of all those factors. In the high, pure oxygen pressure during the plugs out test, Velcro doesn't just burn, it basically explodes. Gus, Ed and Roger paid the price. And yes, Apollo had an inward opening hatch that was presumable safer than the explosive hatch used on Gemini. It was engineered to prevent a repeat of the Gemini accident that nearly killed Gus. It's secured and doesn't open when the capsule is pressurized, just like the doors on modern airliners... So, defined() sometimes does autovivication and can give you a bad day. But i'm sure the original designers implemented it this way to prevent some problems they encountered at the time. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP Also check out my sisters artwork and my rather simple sketches/one-panel comics	[reply]
Re^3: Defined test creates non-empty hash value by LanX (Saint) on Jun 14, 2024 at 12:53 UTC
> Unfortunately, when creating some sparse hashs of arrays I do rely upon autovivification `no autovivification` does pretty much what you (seem to) want, observation and reading is safe, but setting vivifies. Choroba already pointed you to `autovivification` Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l]
Re^4: Defined test creates non-empty hash value by LanX (Saint) on Jun 15, 2024 at 13:48 UTC
> no autovivification does pretty much what you > ... but setting vivifies. But I have to admit that it wasn't apparent for me at first. I think description and synopsis could be improved to highlight that the default of `no autovivification` is a DWIM and not a complete switch off. I leave it to the native speakers... Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l]