Re: Should Test2 maintain $! and $@?

[Chad Granum]

I can add a complex mechanism, or someone can just do this:

sub modifies_err {
> my $ctx = context();
> ...
> my $err = $@;
> $ctx->release();
> $@ = $err;
> return ...;
> }


It is unlikely anyone would want to have $@, $!, and $?, all at once, but
just as easy to manually maintain them. Wanting to preserve any, let alone
all 3 is rare enough, and easy enough, that I think adding a mechanism into
release() or context() would be noise. Add to this the fact that context()
and release() are called so often, and have been written so very carefully
to be as fast as possible, I am not convinced this mechanism is necessary.

Then again, if you /really/ want the mechanism in $ctx, I can add
$ctx->release_preserving (naming is hard, give me a better one) which does
have the behavior... but at that point, which behavior do you want,
preserve one, preserve all, preserve what is requested in arguments? Once
again, seems over-complicated for something done so rarely, and so easy to
just do without a mechanism.

rjbs and I actually talked about this Friday. He asked me how a function
could set $@ if it wanted to, I showed him a sample like the one above and
his response was:

 ->release; $@ = $err;
>  oh, of course
>  Ha, right.  I'm dumb.
>  Thanks!


-Chad

On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis 
wrote:

> * Chad Granum  [2016-01-12 04:20]:
> > That said, it just occured to me that this can possibly be
> > accomplished by having a context store $! And $@ when it is obtained,
> > then restore them when it is released, which would avoid needing to
> > use local everywhere, and still preserve them for all tools
> > automatically...
>
> I actually like the magic Kent is wary about in this instance, as it
> makes it easier for test functions to get this right without each of
> them having to carry extra boilerplate. But this also means that a test
> function which explicitly *wants* to change these variables has to fight
> the framework for it. So maybe there ought to be a mechanism to request
> that they not be restored on context release.
>
> Regards,
> --
> Aristotle Pagaltzis // 
>

Re: Should Test2 maintain $! and $@?

[Chad Granum]

Just realized my response may not have been clear. My response assumes that
context() DOES store $!, $@ and $?. And that release() restores them. I was
saying that it is easy to get around this magic in the very rare case you
want to. Most cases will not have any need to work around it as it is a
typically desired behavior.

On Sun, Jan 17, 2016 at 9:53 PM, Chad Granum  wrote:

> I can add a complex mechanism, or someone can just do this:
>
> sub modifies_err {
>> my $ctx = context();
>> ...
>> my $err = $@;
>> $ctx->release();
>> $@ = $err;
>> return ...;
>> }
>
>
> It is unlikely anyone would want to have $@, $!, and $?, all at once, but
> just as easy to manually maintain them. Wanting to preserve any, let alone
> all 3 is rare enough, and easy enough, that I think adding a mechanism into
> release() or context() would be noise. Add to this the fact that context()
> and release() are called so often, and have been written so very carefully
> to be as fast as possible, I am not convinced this mechanism is necessary.
>
> Then again, if you /really/ want the mechanism in $ctx, I can add
> $ctx->release_preserving (naming is hard, give me a better one) which does
> have the behavior... but at that point, which behavior do you want,
> preserve one, preserve all, preserve what is requested in arguments? Once
> again, seems over-complicated for something done so rarely, and so easy to
> just do without a mechanism.
>
> rjbs and I actually talked about this Friday. He asked me how a function
> could set $@ if it wanted to, I showed him a sample like the one above and
> his response was:
>
>  ->release; $@ = $err;
>>  oh, of course
>>  Ha, right.  I'm dumb.
>>  Thanks!
>
>
> -Chad
>
> On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis 
> wrote:
>
>> * Chad Granum  [2016-01-12 04:20]:
>> > That said, it just occured to me that this can possibly be
>> > accomplished by having a context store $! And $@ when it is obtained,
>> > then restore them when it is released, which would avoid needing to
>> > use local everywhere, and still preserve them for all tools
>> > automatically...
>>
>> I actually like the magic Kent is wary about in this instance, as it
>> makes it easier for test functions to get this right without each of
>> them having to carry extra boilerplate. But this also means that a test
>> function which explicitly *wants* to change these variables has to fight
>> the framework for it. So maybe there ought to be a mechanism to request
>> that they not be restored on context release.
>>
>> Regards,
>> --
>> Aristotle Pagaltzis // 
>>
>
>

Re: Should Test2 maintain $! and $@?

[Aristotle Pagaltzis]

* Chad Granum  [2016-01-12 04:20]:
> That said, it just occured to me that this can possibly be
> accomplished by having a context store $! And $@ when it is obtained,
> then restore them when it is released, which would avoid needing to
> use local everywhere, and still preserve them for all tools
> automatically...

I actually like the magic Kent is wary about in this instance, as it
makes it easier for test functions to get this right without each of
them having to carry extra boilerplate. But this also means that a test
function which explicitly *wants* to change these variables has to fight
the framework for it. So maybe there ought to be a mechanism to request
that they not be restored on context release.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Should Test2 maintain $! and $@?

[Kent Fredric]

On 18 January 2016 at 18:53, Chad Granum  wrote:
> Then again, if you /really/ want the mechanism in $ctx, I can add
> $ctx->release_preserving (naming is hard, give me a better one) which does
> have the behavior... but at that point, which behavior do you want, preserve
> one, preserve all, preserve what is requested in arguments? Once again,
> seems over-complicated for something done so rarely, and so easy to just do
> without a mechanism.


You could possibly make it a parameter to ->release

->release({ no_restore => 1 }) # don't restore anything
->release({ no_restore => [qw( $@ )] })  # only avoid restoring $@

But then you might be slowing down the code-path of "release" by
having an additional condition.

Though I think given how infrequently you'll need nuanced control over
variables, "no_restore => 1" is the only thing you need short term, as
the combination of "preserve everything" or "preserve nothing" are
both simple enough to be useful.

Either way, if preserve/restore are to be done by the context without
any user side control, the simplest way of avoiding
the undesired side effects should be documented to discourage the user
doing cheap tricks that cause future maintenance headaches.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL