Hi! I can take the blame for some of Readonly and all of ReadonlyX!
So, I inherited Readonly to fix a bug that was breaking a dependency 2 or 3 levels up from what I was working on at the time. From what I remember (way back in 2013 or 2014), it was flat out crashing on what was then bleadperl and became 5.20.x. p5p was refactoring magic around tied variables and some undocumented behavior Readonly had been taking advantage of since at least 2002 was finally being fixed in perl itself.
The showstopper I needed fixed didn't change how Readonly behaved but there are still several major bugs that cannot be fixed without harming people. I groan whenever I see Readonly as a dependency to this day because it is so fundamentally broken. I made the most used of Readonly's 3 different APIs almost 50 times (not 50%) faster according to benchmarks without an issue but the guy who talked me into wasting months on deeply, CLONE-able, tie-based immutable vars that'll never work properly better avoid dark alleys. :) If it works for you, great. I don't suggest using Readonly for new code though.
ReadonlyX was just a gist on github until someone asked for it to be uploaded to CPAN and I pushed it as a dist in the middle of the night without much of a plan, updated some of the docs a day or so later, and never even created a repo for it. It was never really meant to be a true drop in replacement for Readonly despite that hasty claim because I consider Readonly broken by design (not the fault of the original author; even brilliant code will become unwieldy and begin to smell after 20 years). ReadonlyX uses perl's internal, fast magic to mark an SV * as immutable, borrowed the least broken of Readonly's 3 different APIs, and maintains predictable behavior over different versions of perl which Readonly cannot promise without breaking darkpan. It never should have been given the name ReadonlyX but, well, it's out there now. | [reply]
[d/l]
[select] |
Hi
Thanks for the feedback and sorry for my maybe overly harsh reaction.
I think the issue with Readonly and ReadonlyX colliding could be easily fixed if you released an extra module - probably in the same distribution - which put's ReadonlyX subs into another namespace before exporting.
Something like ReadonlyX::Proper or ReadonlyXXX (There are for sure better names)
Like this modules using the subs qw/Scalar Array Hash/ from there, won't see strange collision effects, if other modules deeper down use Readonly or ReadonlyX.
I think this could be done without adding much code by refactoring all the code into an extra readonly_code.pl w/o namespace and letting ReadonlyX and ReadonlyX::Proper do the file after declaring their packages.
But of course you are the expert here :)
Thanks for your work!!!
update
OTOH Const::Fast exists and seems to do the job already with a new interface.
If your point was to have a drop-in replacement, I doubt this can be done with those fully qualified subs like Readonly::Scalar without caveats.
Maybe you should just mention those drawbacks in the module's POD.
| [reply]
[d/l]
[select] |
The "buggy and slow" is output from perlcritic, not PBP. | [reply] |
| [reply] |
Agreed...and thank you. As I said in the original post blindly following advice is a recipe for problems...and yes I can exclude Readonly from the list of discouraged modules when running perlcritic. Pipelines controlled by corporate security teams however do not encourage (or sometimes even allow) modification of .perlcriticrc. I appreciate the responses, but my opinion of the wisdom of the advice presented in perlcritic is only sometimes relevant and under my control. Moreover this still leaves me with the issue of Readonly vs ReadonlyX clashing.
| [reply] |