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 <exodi...@gmail.com> 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:
>
> <Exodist> ->release; $@ = $err;
>> <rjbs> oh, of course
>> <rjbs> Ha, right. I'm dumb.
>> <rjbs> Thanks!
>
>
> -Chad
>
> On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis <pagalt...@gmx.de>
> wrote:
>
>> * Chad Granum <exodi...@gmail.com> [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 // <http://plasmasturm.org/>
>>
>
>
