develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
Michael Peters
August 23, 2012 06:45
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
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 

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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About