Front page | perl.perl5.porters |
Postings from August 2012
Michael Peters responded:
> I don't see how it would change it to invalid code, but maybe I'm missing
> something.
We probably mean different things by "invalid".
> If I had this:
>
> my $x = 5;
Let's add a value for $foo:
my $foo = "5.0";
> ... # 30 lines of code
> if($foo ~~ $x) {
This comparison succeeds.
> And then I changed it to this:
>
> my $x = 5;
my $foo = "5.0";
> ... # 10 lines of code
> warn "X is $x";
> ... # 20 lines of code
> if($foo ~~ $x) {
This comparison (mysteriously) fails.
> How has that changed it so that invalid code that proceeds anyway?
Instead of being informed that your code is now unexpectedly failing (by
an exception ruining your day), that code simply proceeds (but
invalidly, without doing the if block).
> My intent hasn't change, nothing (from my perspective) has modified $x.
Agreed.
> What good explanation would exist for why my code would now (not just fail
> to match) but fatally die?
Because the original $foo ~~ $x was (potentially) ambiguous.
Perl doesn't (yet?) properly distinguish between numbers and strings internally,
so smartmatch can't always tell what kind of data you're giving it.
> How would you teach that?
The theory was that the exception itself would teach it:
Ambiguous operand ($x) in smartmatch at example.pl line 7
(Did you mean "$x" or 0+$x?)
> What other place in the language suffers from this problem or is this
> a one-off gotcha?
The bitwise |, &, and ^ have the same "history-sensitivity" problem,
for the same reason: namely, that they work differently on numbers vs strings..
> And as an aside, what would happen if I ran this through the debugger and
> printed a var from there instead of in my code? Would that also change it to
> a dual-var and thus die fatally? What about something like Devel::Trace?
> Would that be unusable on some valid code because it would cause it to die
> fatally?
Yes. Although bear in mind that we're now talking about it just failing
with a warning, rather than dying. So you already won that battle. :-)
> And I think it would be a shame if we expose this gotcha to users.
Amen! Unfortunately, this gotcha seems like the least worst compromise
under the present internals.
> Now, most of my problems with this fatal-ness go away with Chip's magic
> flags work, right?
Right. All of them, I hope.
> So maybe all I'm saying is that making this fatal makes
> no sense without his work along with it.
With his work in place, it actually doesn't need to be fatal either,
as the ambiguity (was it really a number or a string?) would vanish.
"Help us Obi-Chip...you're our only hope!"
Damian
Thread Previous
|
Thread Next