develooper Front page | perl.perl5.porters | Postings from February 2003

Re: Did the assertion patch/feature submission get overlooked?

February 16, 2003 07:19
Re: Did the assertion patch/feature submission get overlooked?
Message ID:
Salvador =?ISO-8859-1?Q?Fandi=F1o?= <> wrote:
:I have been working further on the assertions patch.
:Main change is that now assertion activation status is lexically 
:scooped. I have defined a new flag HINT_ASSERTING for PL_hints (AKA $^H).

Thanks, I've now applied the updated form of the patch as change #18727.
That'll serve as a starting point for discussion.

Note that I've added assertions-0.01/ as lib/,
and assertions-0.01/activate/ as lib/assertions/,
with associated changes to perl's MANIFEST.

I'd appreciate some documentation and tests for the new facilities.

(Joe, note that this adds some debugger features; please see
for the original analysis.)

:In the new version, the -A switch is used with a list of tags:
:     perl -Afoo,bar ...
:and what it really does is:
:     use assertions::activate split(/,/,{foo,bar});
:in a similar fashion to '-M' or '-d:' switches.

I think it would be useful to permit activation of all assertions,
one way or another: perhaps with a bare -A, or perhaps with something
like -A:all. I tried testing with:
  perl -A'.*' -wle 'sub foo : assertion { print "assert"; } foo(); print "ok"'
.. and the assertion was not activated.

Is there any particular reason to have the code of assertions::activate
in a separate package from assertions?

:Other issue is what happens to lexicals declared inside assertion args. 
:Alternative behavior would be to open a new scope for the assertion 
:args, this could be easily done expanding assertion calls to
:     asserting and assertion(@args)

I think this would be the simplest way to guarantee that perl won't
try to look up a different variable depending whether assertions are
enabled or not.

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