I have a read-only type data structure which must be shared between many packages from many developers. We recurse over it and make it read-only after creation using Internals::SvREADONLY before the other packages are loaded begin executing. However, some developers circumvented that with the same subroutine Internals::SvREADONLY. I'm contemplating taking a lexically scoped code ref to Internals::SvREADONLY and then redefining Internals::SvREADONLY to some subroutine which warns them "not to even think about it" when called. In some limited testing this seems to work.
Before I commit this change I was looking for some input on just how terribly bad this idea is. Does anybody know of unintended consequences or other reasons this could cause trouble? Are there other methods to circumvent data that has been marked read-only?
From what I read and tested breaking Internals::SvREADONLY didn't produce any visible problems. But as the monks have pointed out its far from air tight. The route were going now is adding a subroutine to the test suite that checks the DS after loading and executing the modules from other developers. It ensures that the DS is still marked readonly and that it hasn't changed been changed by comparing against an internal copy of the DS. When it discovers changes electric shocks are promptly delivered through the mouses to all SW developers
In reply to redefining Internals::SvREADONLY by ChiefAl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |