Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Wednesday May 30, 2007
05:19 PM

perl 5.10 assertions: friend or foe?

[ #33381 ]

I've been writing mini-articles about some of 5.10's new features for, this past week. It's been fun, and I've learned a few things that I didn't know in the process. The feature that I knew the least before covering it, so far, has been assertions. Assertions let you have code that only runs if some set of assertions are enabled. It's something like this:

sub everything_is_ok : assertion {
  print "Everything is okay!\n";


  use assertions 'foo';

  use assertions 'foo && bar';

If I were to run this program with perl, it would print one line. If I were to run it under perl -A=foo, it would print two. If I were to run it with perl -A=foo,bar, it would print three.

Because assertions must be specified before compilation, it's possible to optimize away the sub calls at compile time, so it's more efficient than just checking, say, $ENV{PERL_ASSERT_FOO}.

I think it's a swell idea, but so far a few things have left me underwhelmed.

First of all, assertions don't prevent method calls. I'm sure that this would lead me to some profound grief in the future, when I find that a subclass really needs a subclassed assertion and I have to do more than just subclass it. It's been mentioned that maybe this (and related woes) will be fixed before 5.10.

The whole interface seems a bit clumsy, though. I had expected it would work like this:

sub everything_is_okay : assertion(wtf) { ... }

...and then this code would only run when "wtf" exceptions were enabled. I guess the problem with this might be that sometimes you'd want it to run and sometimes not -- that's why the assertion's power was moved to the calling block. The thing is, why isn't the whole block compiled in or not? It would solve the problem of method calls, and it would prevent this problem:

sub check_stuff : assertion { ... }

my $code = \&check_stuff;

  use assertions 0; # should prevent all assertions
  $code->(); # ... but this will run anyway

Further, how weird is this:

  use assertions 'debugging';
  my $value = some_assertion;

If the debugging assertion isn't on, $value is set to zero. I'd expect a compile-time death, or at least a runtime death, or at least a result of undef.

The docs for assertions aren't great, yet, but I hope I can help. What I hope even more is that I can find a simple way to use the existing assertions hooks to write mine like this:

sub does_something_fantastic {
  assuming 'foo && bar' {
    my $object = get_object;
    say "foo and bar must be enabled!";

...but then again, maybe someone will just be able to point out why the implemented way is the One True Way To Do It.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.