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?

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.

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.

RIP an inspiration; A true Folk's Guy

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.

I was trying to learn some details about the Internals package

The functions are implemented in universal.c.

Are there other methods to circumvent data that has been marked read-only?

The readonly flag can be turned off.

do you mean there are other core subroutines which disable the readonly flag on a particular variable or is this a global option supplied by a switch?

"Other"? Ah, I didn't realize Internals::SvREADONLY could. Yes, it just exports SvREADONLY_on(sv) and SvREADONLY_off(sv) to Perl land.

It sounds like you are trying to prevent someone from preventing you from making variables read-only. All I pointed out that it's moot since they can undo your work should you manage to get it done.

But you know what, one doesn't even need to make the variable not readonly to change it. The READONLY flag is purely advisory. It can simply be ignored.

use strict;
use warnings;

use Inline C => <<'__EOI__';

void change_it(SV* sv) {
    SvIV_set(sv, 789);
    SvIOK_only(sv);
}

__EOI__

my $i = 123;
Internals::SvREADONLY($i, 1);
print("$i\n");

eval { $i = 456; };
print("$i\n");

change_it($i);
print("$i\n");
[download]

123
123
789
[download]

Update: Added realisation that READONLY if advisory.

Are there other methods to circumvent data that has been marked read-only?

Yes. I thought of three in ten seconds. Two are trivial and one is easy.

As the other commenters suggest, you don't have a technology problem here.

Be well,
rir

If you have to worry about developers poking the internals of your objects, and you can't get control of it by social means, you also have to worry that those same developers might use PadWalker to penetrate the barrier that inside-out objects build to protect their privacy.

As was pointed out several time this is a social problem, and probably can't be solved by technical means.

that looks promising in the future... thanks