Bug #96801 for Acme-Presume: Doesn't actually disable strict or warnings

Sat Jun 28 23:22:16 2014 KENTNL [...] cpan.org - Ticket created

Subject:

Doesn't actually disable strict or warnings

I saw this module hit the release feed and got curious as to how it worked .... and then saw the source and realised it probably didn't really work as you intended, which may be some misunderstanding how 'eval', 'strict' and 'warnings' work.

strict and warnings affect their *compilation* scope at *compile* tiime, so turning off strict and warnings inside the eval **doesnt** turn off strict and warnings in the context that defined the sub.

And this is a problem, because the sub itself is compiled *before* passing it as a parameter to presume().

Attached are some examples of how it doesn't quite do what you think it does:

- strict 'refs' is still strict, just when it fails, it gets eaten by eval ( x is 2 )
- strict 'vars' fatalises during compile time, so you have a compile failure before presume() ever gets called. ( commented out )
- warnings are compiled in at compile time, but their effects are only visible at runtime. ( yielding uninitialized value warning )

Hope that helps. =)

( I know acme modules are just for fun and learning things, so I figured maybe you were learning things, apologies if I'm telling you things you already know =) )

Subject:

presume.t

use strict; use warnings; use Test::More; # ABSTRACT: Show presume is wrong use Acme::Presume qw( presume ); my $x = 0; presume sub { $x = 1 }; ok( $x, "Presume ran" ); presume sub { $x = 2; *{"::main::naughty"} = \sub { "hello" }; $x = 3; }; is( $x, 3, 'Strict aint a problem' ) or diag $@; ## uncomment for a compile time error # presume sub { # $y = 3; # strict vars # }; presume sub { my $y; "$y" # Use of uninitialized value $y in string at /tmp/presume.t line 30 }; done_testing;

Sun Jun 29 09:11:50 2014 NMELNICK [...] cpan.org - Correspondence added

I am amused that a humorous module got a ticket so quickly, but I do appreciate it. I spent most of my time making sure the eval did what I want before even paying attention to the reality of what I was doing. This is useful -- I will noodle on this a while. :) Thank you for the reply! On Sat Jun 28 23:22:16 2014, KENTNL wrote: Show quoted text

> I saw this module hit the release feed and got curious as to how it > worked .... > and then saw the source and realised it probably didn't really work as > you > intended, which may be some misunderstanding how 'eval', 'strict' and > 'warnings' work. > > strict and warnings affect their *compilation* scope at *compile* > tiime, so > turning off strict and warnings inside the eval **doesnt** turn off > strict and > warnings in the context that defined the sub. > > And this is a problem, because the sub itself is compiled *before* > passing it > as a parameter to presume(). > > Attached are some examples of how it doesn't quite do what you think > it does: > > - strict 'refs' is still strict, just when it fails, it gets eaten by > eval ( x > is 2 ) > - strict 'vars' fatalises during compile time, so you have a compile > failure > before presume() ever gets called. ( commented out ) > - warnings are compiled in at compile time, but their effects are only > visible > at runtime. ( yielding uninitialized value warning ) > > Hope that helps. =) > > ( I know acme modules are just for fun and learning things, so I > figured maybe > you were learning things, apologies if I'm telling you things you > already know > =) )

Sun Jun 29 09:11:50 2014 The RT System itself - Status changed from 'new' to 'open'