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

In reply to Re^5: Moose or Mouse for production use by stvn
in thread Moose or Mouse for production use by morgon

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.