develooper Front page | perl.perl5.porters | Postings from June 2007

Re: assertions, warts and all

Thread Previous | Thread Next
From:
Yitzchak Scott-Thoennes
Date:
June 3, 2007 21:06
Subject:
Re: assertions, warts and all
Message ID:
37056.67.42.99.191.1180929955.squirrel@webmail.efn.org
On Sat, Jun 02, 2007 at 12:34:55PM -0400, Ricardo SIGNES wrote:
> * Yitzchak Scott-Thoennes <sthoenna@efn.org> [2007-06-01T16:13:46]
> > On Thu, May 31, 2007 5:38 pm, Ricardo SIGNES wrote:
> > > PROBLEM: selective deactivation within a block is confusing
> > >
> > > Because only SOME code gets deactivated inside a block with assertions
> > > declarations, weird things can happen.
> > > {
> > > use assertions 'validation'; die unless everything_is_fine; }
> > >
> > > If everything_is_fine is a subroutine marked with :assertion, and
> > > assertions are not active, it will return 0, and we will die -- even
> > > though the code was never run.  Maybe this is the programmer fault, but
> > > clearly the language is not straightforward, here.
> >
> > I completely miss what problem you see here.  Do you want a means of
> > (optionally) providing a constant to replace optimized-away assertions,
> > so everything_is_fine is either called or replaced with sv_yes, or
> > some other value provided in the attribute?  That seems like not a
> > (where assertions would either be called in void context or where
> > your example would have to be "die if all_is_lost_give_up_the_ghost"
> > instead).
>
> I agree that "basic assertions" can be done with this system, but it
also lends
> itself to helping people make the stupid mistake I described.  "Just
don't do
> that!" is not, imho, a great solution.  A better one might be,
"optimized out
> assertion calls cause an exception in non-void context," but that, too,
seems
> byzantine.
>
> Again, I think the solution here is that assertions should be blockwise,
not
> expressionwise.

Maybe I'm missing something, but that seems like completely different
functionality.  Can you show a realistic use case?

It puts the onus of stating that code is conditional everywhere
you want code to be so.  You can already do that just fine with:

use constant ASSERTION_FOO => $ENV{FOO};

if (ASSERTION_FOO) {
   ...
}

so I see absolutely no benefit to it, other than as the slightest
bit of syntactic sugar.  It also doesn't actually solve the problem
I think you are describing, since context propagates into blocks
(and hence values out of them) just fine.

The benefit I see to assertions as they are (assuming no one
has modified them to auto-croak) is to simplify code like this

use constant LOG_LEVEL => LOG_INFO | LOG_TRACE | LOG_DATA;

sub do_command {
   log('entering do_command')
      if LOG_LEVEL & LOG_TRACE;

   my $self = shift;
   my $command = shift;

   log('sending command', $command)
      if LOG_LEVEL & LOG_DATA;
   my $send_result = $self->send_command($command);
   log('send_command result', $send_result)
      if LOG_LEVEL & LOG_INFO;

   my $command_response = $self->command_response();
   log('command response', $command_response)
      if LOG_LEVEL & LOG_DATA;

   log('leaving do_command')
      if LOG_LEVEL & LOG_TRACE;
   return $command_response;
}

into (with suitable assertion subs defined):

sub do_command {
   log_enter();

   my $self = shift;
   my $command = shift;

   log_data('sending command', $command);
   my $send_result = $self->send_command($command);
   log_info('send_command result', $send_result);

   my $command_response = $self->command_response();
   log_data('command response', $command_response);

   log_leave();
   return $command_response;
}


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About