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

Re: assertions, warts and all

Thread Previous | Thread Next
Yitzchak Scott-Thoennes
June 1, 2007 13:14
Re: assertions, warts and all
Message ID:
On Thu, May 31, 2007 5:38 pm, Ricardo SIGNES wrote:

caveat porter: I'm responding to this before reading the responses
of others, and it's been a long time since I looked at the assertions
stuff (and my main impression then was that the implementation was
not well enough documented, especially on the example front).

> 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
bad feature, but not necessary for basic assertion functionality
(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"

> PROBLEM: only named subroutines calls are affected
> I've mentioned this before, so I won't linger, but a call to a method or
> a reference to a named sub will not be properly deactivated.

I have no problem with the current behaviour, if documented.
I'd even find it somewhat surprising if a method call or call
by reference were suppressed.  The goal of assertions as I
see it is to have a compile-time effect, not a run-time effect,
and suppressing those other types of calls seems clearly
run-time to me.

> PROBLEM: the meaning of @{^ASSERTING} is ill-defined

This is a problem.  If we're going to allow alternate assertions modules
outside the core, how @{^ASSERTING} works is part of the public API.

> PROBLEM: assertions::compat
> What a mess.  It's not really compatible, it's just another
> implementation of assertions.

No, it's not, AFAICT.

> Its docs suggest that you should add
> assertions::compat to your
> @ISA wherever you want to use it.

AIUI, it's purposes are to supply a do-nothing :assertion attribute
when used on older perls and a way to query if assertions are
supported.  WRT the first purpose, if you want to use an assertion
routine in your CPAN module Foo, and have it not get called when
others use your module under 5.10, you use assertions::compat and
list it as a prereq.  There is a slightly greater incentive to add
a prereq if it is something that will be in the core in the future,
so maybe that's a reason to keep it?  The second purpose is a more
straightforward reason for being in the core.

> * update assertion check to use ~~ and document @{^ASSERTING}
> I am happy to submit this patch, but ... is there a reason not to?

Do you mean ~~ instead or in addition to the ->check() call?
~~ will be harder to emulate on an older perl if someone does
try to make an :assertion attribute that creates a wrapper
function that conditionally calls the real function.

> * supply a means to assert entire blocks away
> asserting EXPR { ... }
> If the assertion expression is true, the block is executed.  If not, it
> isn't.  This could be done really easily as subroutine (if the block was
> given as a sub) but I think this needs core hacking to make it work (a)
> as a compile-time optimization and (b) with a bare block.

Bleah.  That doesn't seem related at all to the rest of the
assertions functionality.  I think we get enough confusion over
the compile-time expression in "use Foo EXPR" that I hesitate to
want another instance of implicitly compile-time expressions.

> With this done, I see no reason for "assertion" to be a core attribute.
> It
> will just lead to the confusing partial-expression-evaluation shown above.

which I didn't understand, so can't comment on.

> * remove assertions::compat from core
> This is not needed, but stops suggestion that the porters believe it's
> actually compat.  Also, why put the only-needed-for-older-perl module in
> the core of the new versions?

See above.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About