in reply to redefining Internals::SvREADONLY

However, some developers circumvented that ...

If the developers are internal...the threat of the sack would probably do it.

If they are external, why do you feel the need to dictate this to them? If they screw themselves up, does that affect you?

This isn't sarcasm. Most every occasion when I've seen programmers worrying that other programmers might defile the sacrosanctity of "their" data, there has been no good reason behind it. There's a quote I can't find about "Perl doesn't stand guard with a shotgun" that is probably applicable.

Update: Found the quote:

Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun -- Larry Wall

Programming is about getting the job done. If other programmers feel the need to violate your rules in order to get their job done, it might be because your rules need changing?

If the read-onlyness of this data is absolutely paramount, then there are ways to create read-only memory segments where the read-onlyness is enforced by the hardware. That would generally require some considerable effort to do from Perl, but if it is worth that effort, it can also be backed by OS-level permissions(*) making it extremely hard to circumvent.

(*)Assuming that you can control the permissions used by the other developers?

Replies are listed 'Best First'.
Re^2: redefining Internals::SvREADONLY
by ChiefAl (Initiate) on May 05, 2010 at 23:17 UTC

    I knew I was going to get a response like this. I know PERL's attitude towards enforced privacy and I'd agree that in general its a good approach. However in this situation we really need this data structure read-only. We have had so many hard to trace bugs because developer A changed some variable (sometimes inadvertently) that then screwed developer B. And then finger pointing and hate mongering ensues. The developer who went and made the DS writable was certainly breaking the rules. I was just wondering if there was a way to really enforce the rules this time. And more specifically I was trying to learn some details about the Internals package and what might happen if I start messing with it.

[reply]
      We have had so many hard to trace bugs because developer A changed some variable (sometimes inadvertently) that then screwed developer B...The developer who went and made the DS writable was certainly breaking the rules.

      Setting the data structure writable can't be done "inadvertently".

      If it happens once; you put it down to 'didn't know better', admonish the guy and move on.

      If it happens twice; you put it down to 'thinks he know better', give the guy a written formal warning that any repetition will be considered deliberate sabotage, and result in both dismissal, and reporting to the authorities with a view to criminal prosecution.

      And more specifically I was trying to learn some details about the Internals package and what might happen if I start messing with it.

      Anything you can do--your malicious programmer can undo. Far better to be rid of the problem than chase a protracted technological arms race.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I think before you start "messing" about with the "Internal package" you need to think how you'll sandbox your changes until they're proven acceptable.

      And regardless of whether the dev who changed the DS +r was willfully "breaking the rules" or merely ignorant thereof, you have a discipline problem; not a Perl problem, IMO. That's an opinion furthered by your reference to "finger pointing and hate mongering" -- as that's hardly a sign of community values that will help your organization achieve its goals.

      In short, I have to go with BrowserUk's observation, "the threat of the sack...," or, in Americanized form, "Someone with sufficient authority to do so (you?) needs to tell this sucker that you won't need and won't use his/her services if s/he fails to respect the organization's rules and standards."

      Life, human and corporate, is too brief to waste time on aggravations like this.

[reply]

      I was trying to learn some details about the Internals package

      The functions are implemented in universal.c.

[reply]
[d/l]

In Section Seekers of Perl Wisdom