Paul Seamons

• About: I blog about Perl.

Recent Actions

• Commented on A follow up on three-value logic in Perl
  I apologize that this post will sound pessimistic. There just seem to be many "modern perl" solutions being presented in the past few years that are actually only waterbed solutions: that as you push on this problem over here...
• Commented on Does Perl (5) have a future?
  @Joel - You have now asked two questions: Does Perl (5) have a future? and now you have asked: Is it worth sticking with this Perl 5? Does Perl 5 have a future. Yes it does. Is it worth sticking...
• Commented on Does Perl (5) have a future?
  Do you love Perl (mostly rhetorical)? It is obvious you do. I have only been using Perl since 1997. I have a few CPAN distributions. Some of them are useful, some are not. I love Perl. I write nearly everything...

Comment Threads

• Ovid commented on A follow up on three-value logic in Perl

  The various points you raise are value, but you've missed an extremely important use case:

  Real-world code

  In reality, what we should or should not be doing is often a matter of debate and sometimes systems in grow in unexpected ways and have surprising interactions, or we're facing a tight deadline and need to rush things into production.

  One thing I've done is added a fatal option which makes all interactions fatal so if we have a case where a dread "undef" (unknown) shows up and we fail to catch it, we'll get a fatal error if we do anythi…

• J David Eisenberg commented on A follow up on three-value logic in Perl

  Maybe I'm not thinking this through carefully enough, but, since undef coerces to zero, couldn't the original problem be solved with:

  if ( $employee->salary > 0 &&
   $employee->salary < $threshold )

  Also, is unknown analogous to NaN (not a number)? Unlike unknown, NaN compares false to everything, including itself.

• Ovid commented on A follow up on three-value logic in Perl

  J David Eisenberg: that looks tempting and it might be right for some code. However testing for $employee->salary being greater than zero skips a use case: what if an employee's salary is legitimately at zero and they should have the increase?

  Or we could skip the "salary" idea altogether and talk about any situation whereby something might need adjustment and undef gets coerced to zero when, in fact, it might not actually mean that. If a distinction is needed between undef and zero and it's not made, code can easily make bad assumptions.

• Buddy Burden commented on A follow up on three-value logic in Perl

  The problem with ditching the stringification is that it could make debugging problematic.

  I'm interested to see where this goes.

• Ovid commented on A follow up on three-value logic in Perl

  Try the "fatal" option. Stringification is ditched, but it gives you a nice stack trace so you can (hopefully) figure out how you got there.