XP is just a number | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Howdy!
There's a whole bunch of misdirection in them thar comments... use strict; #try to catch as many type errors as possibleWrong... The strict pragma is meant to "restrict unsafe constructs", according to its POD. This is not the same thing as "catching type errors". See below for applications... Misleading... This isn't "type coercion". This is "evaluation in a scalar context". A reference is a species of scalar that numifies to the memory address of its referent. No coercion here. It's still a scalar. Misleading again. This is "evaluation of a hash in a scalar context". I'm not sure what is actually amusing about the result. It's all there in the documentation. They are both collections, so one could group them as the same meta-type, but they have different characteristics that warrant treating them as different types. The assignment is simply "evaluation of a hash in a list context". 'for %c' produces the same situation. As usage goes, it's value is limited. The assignment sets up a list context, in which there is only one item, the "12". I don't see "type coercion" here either. The two 'print' statements are unremarkable demonstrations of evaluating an array in list and scalar contexts. The output of this line lies. \4 produces a different value than does \4->{"what???"}. In the debugger, 'p \4' prints a ref to a scalar; 'x \4' shows that '4' is the referent. The numeric part of the ref is different from that printed by this line, which is, in fact, a scalar reference to an undefined value. What was this supposed to demonstrate? Further fun with perl -MO=Deparse finds that this print is parsed as How interesting... $scalar_list demonstrates the comma operator in action. What are you trying to demonstrate here? What did you intend to demonstrate with %hash_list? Where does "coercion" come into play here? Oh? How do you demonstrate that? I note that you "cleverly" turn warnings off so the casual observer won't see "Odd number of elements in hash assignment" pop up from the assignment, nor "Use of uninitialized value in print" from the print. What do you think is actually stored in %i? Iterate over the keys and dereference them, if you dare. Hint: it won't work. Spectacularly. Further investigation with Deparse show that this is parsed as creating the list context from which it expects to get an even number of items. The same condition applies above at 'my @t=12;' Why turn strict off here? Which facet of strictures were you hoping to sneak by here? Pray explain. Deparse reports a triple dollar sign, not a double. So, to get to the bottom: bad troll; no biscuit.
yours, Michael In reply to Re: strong typing
by herveus
|
|