Re^3: Why do I (sometimes) get a REF ref and not a SCALAR ref?

My understanding is the three variables you listed are actually stored in the same dictionary entry, but as 'x (as a scalar)', 'x (as an array)' and 'x (as a hash)'. The appropriate value or list is returned based on the context.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Comment on Re^3: Why do I (sometimes) get a REF ref and not a SCALAR ref?

Replies are listed 'Best First'.
Re^4: Why do I (sometimes) get a REF ref and not a SCALAR ref? by ikegami (Patriarch) on Jun 24, 2016 at 17:07 UTC
Package vars are stored in an instance of a struct called a typeglob, glob or GV. The appropriate variable is fetched when needed. `$ perl -E' say \x; # Prints the address of the glob. say \@x; # Prints the address of the array. say x{ARRAY}; # Prints the address of the same array. say \%x; # Prints the address of the hash. say *x{HASH}; # Prints the address of the same hash. ' GLOB(0x2f78fd8) ARRAY(0x2f79080) ARRAY(0x2f79080) HASH(0x2f79038) HASH(0x2f79038)` [download] None of this is relevant here. The program is printing the address of three different anonymous scalars that all got allocated at the same address (which is possible since none of the three existed at the same time).	[reply] [d/l]
Re^4: Why do I (sometimes) get a REF ref and not a SCALAR ref? by kennethk (Abbot) on Jun 23, 2016 at 18:39 UTC
That's what I thought, but choroba's reply implies it's just really fast garbage collection or persistent scratch space. This gets into deeper waters than I'm used to. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply]