Re^4: Checking for duplicate subroutine names

[SirBones]

I do appreciate the advice and concern, but in this case really no worries. These are isolated test beds (really isolated, they could have no possible contact with any of our production systems; for that matter their network interfaces are limited to the systems they are testing, which themselves have no external connections), with custom Linux images and dedicated hard wired interfaces. Root access is global. We end up rebuilding these things every few weeks (or days) for a number of reasons; if a user sat down and managed an "rm -rf *" I'd simply call him a bloody twerp, take away his Men's Room key, and put a new image on the thing. (I'm lying; we don't have Men's Room keys.)

The security commentary is appreciated and understood but really not a concern in this case. My concern about duplicate subroutine names is entirely based on accidental over-writes, not maliciousness. A malicious or disgruntled user would have lots of better and more effective targets. To vent hostility on the systems I am referring to would be a shamefully unsatisfying exercise for the perpetrator. (And half the time, particularly on a Friday afternoon, I wouldn't mind if they did crash a system or two.)

-Ken

[pokki]

Then you can just declare your subs in packages, as others have already said. To overwrite your own subs, users would need to name them with their fully qualified name, e.g. package Plugin; sub Core::overwritten_routine { return "foo" }. That is rather hard to write by accident.

After that, the only thing I can see to prevent (probably malicious, at this point) users from overwriting your subs is whipping up some PPI and checking any source files you require before actually requiring them. With your setup and in your environment, the hassle is probably not worth it.