dagolden writes "I've posted slides from my
Inside-Out objects talk at Perl Seminar New York.
Inside-out objects have gained substantial attention as a recommendation in
Perl Best Practices, but bring substantial complexity and are not universally
welcomed. My talk reviews the pros and cons, teaches the basics of the inside-
out technique, and provides a quick overview of inside-out tools on CPAN. It
is aimed at an audience already familar with basic object-oriented Perl and
gives the required background on inside-out objects to reach an independent
conclusion of the worth of the technique."
I haven't tried any of the modules mentioned in this talk (and nor have I heard the talk itself), but the slides give the impression that Object::InsideOut and Class::InsideOut are good and Class::Std not-so-good.
Damian has commented that Object::InsideOut is not ‘secure’, in the sense that it's still possible to break encapsulation (whereas it isn't with Damian's Class::Std).
The slides don't address this point at all. Is it a valid criticism of the 2 modules being recommended by the talk? Or has it been addressed in more recent versions? Or do the authors of those modules consider this to be a non-issue — and if so, why?
Cheers.
Smylers
Re:Forcing Encapsulation
dagolden on 2006-01-20T21:08:14
Object::InsideOut is insecure in the sense that the inside-out index is stored inside the blessed scalar. However, that scalar is subsequently made read-only (on sufficiently advanced versions of Perl 5.8), so it can't easily be subverted.
On the other hand, nothing in Perl is really that secure if you can run arbitrary XS. Something like PadWalker can easily violate lexical encapsulation -- including that of Class::Std.
Object::InsideOut makes it hard enough that you can't do it by accident and actually have to work to subvert it. For many people that's sufficient.
That said, it's important to remember that encapsulation -- from an OO sense -- isn't about protecting data so much as it is about avoiding coupling. I.e. external code should use your class' interface, not its internals. With classic objects, it's as easy to violate as dereferencing the object. With inside-out objects, it requires delving into the guts of the Perl interpreter -- not something lightly or commonly done.
At the back of the slides, there's a comparison of the various modules. Class::Std suffers in that it's not thread safe and doesn't support foreign inheritance. It also uses its own custom attribute handling that isn't compatible with Attribute::Handlers and thus doesn't work with some of the other attribute-based helpers that Damian recommends.
FYI, Class::InsideOut uses memory addresses so is "secure" in Damian's sense of the term.
