Re^4: Moose or Mouse for production use

Replies are listed 'Best First'.
Re^5: Moose or Mouse for production use by stvn (Monsignor) on Apr 01, 2009 at 23:55 UTC
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	[reply] [d/l]
Re^6: Moose or Mouse for production use by roubi (Hermit) on Apr 02, 2009 at 01:35 UTC
I can't speak to the OP's reasons for liking the type of encapsulation offered by Class::Std, but in my personal (professional) experience the threat against proper encapsulation (and the consequences this has on code maintainability) doesn't come from the sophisticated and determined Perl hacker but rather the cube neighbor or remote colleague (or even myself) who is either used to dealing with native Perl objects or is having a day off. In that context, the protection offered by InsideOut objects is good enough. It's akin to locking your car in the parking lot. It makes clear you don't wish anybody to get in.	[reply]
Re^7: Moose or Mouse for production use by stvn (Monsignor) on Apr 02, 2009 at 01:50 UTC
It's akin to locking your car in the parking lot. It makes clear you don't wish anybody to get in. Actually I think Inside-Out objects are more like a car alarm system. If you try and mess with it, it will likely complain very loudly but ultimately it can be bypassed by the determined. IMO, simply using accessors is "locking your car" because OO Best Practices already dictates that you should always use accessors to get at your slot data. -stvn	[reply]
Re^5: Moose or Mouse for production use by stvn (Monsignor) on Apr 02, 2009 at 00:17 UTC
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	[reply]
Re^5: Moose or Mouse for production use (intent) by tye (Sage) on Apr 02, 2009 at 04:32 UTC
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	[reply] [d/l]