in reply to Hitting head against wall over Readonly compilation errors

Hi, I had no problem running the first part of your sample, so I guess your problem is within cgiapp_init and the error message addresses that part of your module. Since that sub is likely located in another package than %__DFV_DEFAULTS, something like \%main::__DFV_DEFAULTS might work?

Replies are listed 'Best First'.
Re^2: Hitting head against wall over Readonly compilation errors
by SilasTheMonk (Chaplain) on Sep 12, 2009 at 12:57 UTC
    A provisional test indicates that this works (a little more to do before I break out the port to celebrate). However I am still puzzled as to what is going on here. Is the Readonly module forcing the variables into the global space? Surely that would be something terrible.
      Is the Readonly module forcing the variables into the global space? Surely that would be something terrible.

      No. perldoc -f our 'our' is not 'my'

        Okay it's starting to make sense. The following does what I would expect:
        use Readonly; sub testvalue { Readonly my %hash => {h =>1}; return \%hash; } my $h = testvalue(); $h->{h} = 2;

      Is the Readonly module forcing the variables into the global space? Surely that would be something terrible.

      There is no such thing. main:: could be considered the root namespace, but it's no more or less global than any other namespaces.

      Furthermore, Readonly doesn't move or create variables. It simply alters the variable you pass to it to make it readonly. If you pass it a variable in the main:: namespace, it'll affect a variable in the main:: namespace. If you pass it a variable in the Foo::Bar:: namespace, it'll affect a variable in the Foo::Bar:: namespace. It you pass it a lexical variable, it'll affect the lexical variable.

        Yes I understand what is going on now. Thanks to everyone for educating me in what "our" means. I really had not quite grasped it.