Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^5: Warnings not being thrown with DBI (nits)

by tye (Sage)
on Sep 11, 2005 at 17:48 UTC ( #491077=note: print w/ replies, xml ) Need Help??

in reply to Re^4: Warnings not being thrown with DBI (nits)
in thread Warnings not being thrown with DBI

$href->{id} is being autovivified (it wasn't there before, it is there afterward). The expression, $href->{id}, by itself, isn't enough to make the autovification happen. I just showed one way it can be autovivified. It doesn't require that method.

Claiming that hash entries are never autovivified, seeing a check of a hash entry used to autovivify an entry in a hash, and then claiming no conflict is pretty fine hair splitting in my book, especially when you started the picking of the nits.

Since the original code did not show the code for execute(), I was just showing that that exact code certainly could autovivify $hash->{id}.

main->execute( $href->{id} ); sub execute { my $sum= 0; for( @_ ) { $_ ||= 0; $sum += $_; } return $sum; } print keys %$href, $/;

(prints "id")

It is actually somewhat complex magic that allows the undef that gets passed into execute() to be able to autovivify the hash entry at quite a distance (and thus also allows the autovivification to be avoided in some cases).

The lack of immediate autovivification is actually in conflict with the documentation, IMHO, because $href->{id} is being used in an lvalue context just by virtue of being passed directly to a function. I'll have to dig up some old versions of Perl, because I believe the autovivification used to happen immediately instead of being delayed by such magic. I also found a bug in this magic in a node a few years ago...

- tye        

Replies are listed 'Best First'.
Re^6: Warnings not being thrown with DBI (nits)
by ikegami (Pope) on Sep 11, 2005 at 20:59 UTC

    ||= 0 is clearly an explicit assignment, not an automatic one. While I could agree with you in your earlier example, I certainly don't equate "creation through assignment" with "auto-vivification", even when dealing with references.

      It isn't assigning to $href->{id}, it is assigning to a magic "alias" (at a distance) which autovivifies the key and value pair. I especially consider it autovivification because the assignment creates the key even though the key is not mentioned in the assignment code. I also consider it autovivification because it is just a special (delayed) case of the following:

      To show the autovivification of a hash entry more clearly, just do \$hash{id} (using a hash entry in an lvalue 'context').

      Or, to be closer to the original code, consider

      for( $hash{id} ) { # ... } print keys %hash, $/;

      Which hasn't (yet?) been made to delay the autovivification step like was done for function arguments.

      - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://491077]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2016-08-28 07:18 GMT
Find Nodes?
    Voting Booth?
    The best thing I ever won in a lottery was:

    Results (391 votes). Check out past polls.