|The stupid question is the question not asked|
Re: Readonly oddityby mr_ron (Chaplain)
|on Jan 28, 2016 at 00:58 UTC||Need Help??|
> ... with these versions of Perl and Readonly ... it (fails silently)
The script with Perl 5.20/Readonly 2 looked broken to me too, but I now understand that instead of failing silently the older Perl/Readonly refused to run and probably issued an error message like:
So allowing assignment to run and leave an undef value seems at first to be a new surprising feature (bug) with Readonly.
On looking closer at the problem the change is, as tangent suggested, more because of changes in Perl than in Readonly. With Perl 5.14 I get the same error whether I use Readonly 1.03 or 2. If I use Perl 5.22 then Readonly 1.03 gives the same silent/undef behavior as Readonly 2.
Readonly uses subroutine prototypes and there has been a change in subroutine prototype behavior with newer versions of Perl. As described in proto documentation, both 5.14 and 5.22 allow:
Newer Perls also allow:
whereas in Perl 5.14 the above code gives the familiar looking error:
The new behavior seems to me to be a reasonable extension from a language perspective but, even if Perl is causing the change, one result of the new proto behavior in Perl is a change in the behavior of Readonly that I understand to be undesirable even if it makes undocumented use of the module. I agree and understand the mistake could be easy to make.
In the original post the poster asked:
> Is this a known problem?
I did not see it listed under the CPAN/git module issues or anything in RT. There is an odd hint added to the documentation for Readonly 2 that wasn't in the older documentation.
So allowing for a Readonly scalar with a default value of undef is now documented as allowed. "Readonly my $var;" actually worked with Perl 5.14 and Readonly 1.03 too.
The original poster had two suggestions:
I played with patching Readonly.pm both ways and view either to be feasible. For somewhat complicated reasons that sort of boil down to extensive efforts by the Readonly code bending over backwards to be backward compatible, I am somewhat in favor of the first approach of issuing an error for this usage.
In summary, I feel a bug report for the module is merited by the problem but would be interested in feedback from other monks.
A sample patch for the problem for Readonly 2 is included for informational purposes. It passes the test suite but shouldn't be applied by anyone depending on the module.