Moose does not attempt to solve this, mostly because we see it as a social problem rather then a technical problem.

If a co-worker writes code that accesses the underly HASH ref then they are breaking encapsulation (as well as general community coding standards). Once you discover this violation, you should talk to that person and explain why they shouldn't do it. If said co-worker continues to do this, then they should likely be fired or at least disciplined.

Encapsulation is just a concept, something you can use to help write better code with. Encapsulation is not about completely preventing access to slots, but about providing clean and controlled ways to access slots. Moose accessors provide exactly that, a clean, consistent and controlled way to access your object's slots. What Class::Std (and all the other Inside-Out object systems) do is really just obsfucate slot access, an enterprising hacker can easily get past that encapsulation using modules like B and PadWalker.

... can you mix Moose and Class::Std?

Not at all, they are two conflicting systems.

Having to be constantly on the lookout for encapsulation breakage isn't fun nor practical. There is no need for anybody to get fired or even disciplined over this either. Much better have the code catastrophically fail and the co-worker given the opportunity to fix their mistake. Which is exactly what the various Inside-Out schemes out there provide (like my favorite Object::InsideOut).

First, let me say that these are my opinions and nothing more, feel free to ignore/dismiss them according to your tastes. Now, let me clarify my points a little more ...

Having to be constantly on the lookout for encapsulation breakage isn't fun nor practical.

Agreed, I am not at all suggesting you do this at all because I am assuming that your working with adults who know how to follow simple rules. Not accessing an object's slots directly should be policy and if you have people in your group violating that policy then you have a social problem, not a technical problem. You can not solve this kind of anti-social behavior with technology, you can only throw up simple roadblocks and try to discourage. In the end it can only be solved socially.

IMO, if you feel you have to be constantly on the lookout for encapsulation breakage, you have much bigger problems then encapsulation breakage.

There is no need for anybody to get fired or even disciplined over this either.

Sorry, you are correct. I was more referring to the issue where a worker blatantly disregards stated policy on a consistent basis and either refuses to comply or argues it to death wasting everyones time. At this point (again) you have a social problem and no amount of technology will solve it.

Much better have the code catastrophically fail and the co-worker given the opportunity to fix their mistake.

This is apples to oranges. If a programmer tries the following on an Inside-Out object it just won't work.

$o->{foo} = 10;
[download]

In order to break encapsulation on an Inside-Out object you must be devious and sneaky and if done right you won't get that catastrophic failure to tell you they are breaking encapsulation. So really, Inside-Out just makes it harder (as I said, it obsfucates, not prevents) to break encapsulation, it does not stop it. Ultimately you will have to find the violation either through a side-effect error or through a code review, and no matter what in the end you will find yourself sitting down and talking to the violator and solving the real issue socially.

In actuality the issue is not that they violated encapsulation and accessed the object's internals directly, but that they violated the stated policy which said to not do that.

Which is exactly what the various Inside-Out schemes out there provide (like my favorite Object::InsideOut).

No, Inside-Out objects just make it harder to violate encapsulation, they do not prevent it. Even the tallest fence won't prevent someone who is determined to get over it. And as I have said above, in the end you have to confront the violator and deal with it socially.

-stvn

Ah ha, I knew CPAN would deliver!

You might find Acme::RightSideOutObject interesting, it is only for Class::InsideOut but it is enough of a proof of concept to show that Inside-Out objects only provide a false sense of security.

UPDATE

Found another one that might be interesting autobox::Closure::Attributes. It is not specifically about Inside-Out objects, but it does illustrate that with Perl you can never really hide.

-stvn

If you have to be constantly on the look-out for co-workers breaking encapsulation, then you have a major training problem. Do you also have stuff in place to make system( "rm -rf /" ) harmless and a fatal error? Having to be on constant look-out for programmers deleting everybody's files seems like a much worse problem. Strangely, I don't have either problem from any of my co-workers.

Summary: Preventing accidental violations of good practices == good; trying to prevent intentional violations of good practices == bad (too much work, won't actually work, usually leads to worse hacks, etc.).

- tye