Front page | perl.perl5.porters |
Postings from August 2012
On 08/22/2012 07:37 PM, Damian Conway wrote:
> Michael Peters wrote:
> So you'd prefer a scenario where it turned valid code into invalid
> code, but then
> let that invalid code proceed anyway?
I don't see how it would change it to invalid code, but maybe I'm
missing something. If I had this:
my $x = 5;
... # 30 lines of code
if($foo ~~ $x) {
...
}
And then I changed it to this:
my $x = 5;
... # 10 lines of code
warn "X is $x";
... # 20 lines of code
if($foo ~~ $x) {
...
}
How has that changed it so that invalid code that proceeds anyway? My
intent hasn't change, nothing (from my perspective) has modified $x.
What good explanation would exist for why my code would now (not just
fail to match) but fatally die? How would you teach that? What other
place in the language suffers from this problem or is this a one-off
gotcha?
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?
And I think it would be a shame if we expose this gotcha to users. As
far as I can tell, dual-var-ness is an implementation detail and is
never mentioned in the Camel book.
Now, most of my problems with this fatal-ness go away with Chip's magic
flags work, right? So maybe all I'm saying is that making this fatal
makes no sense without his work along with it.
--
Michael Peters
Plus Three, LP
Thread Previous
|
Thread Next