Inside-Out Objects for Perl – I’m not convinced

When I’ve found Inside-Out Objects not only mentioned but suggested inside Perl Best Practices (see "Always Use Fully Encapsulated Objects" section) I thought: “Cool, here’s a solution to enforce encapsulation on Perl classes. This was badly needed”. But then, the list of advantages wasn’t too exciting, while the drawbacks were quite scary… See for example this analysis.

To simplify the problem, note that all I want is: “a mechanism to prevent an object attribute to be read or changed from outside the object”. In Java, C++, PHP, you just declare that class attribute as private. Simple. (Python has a form of “privatization by obfuscation” that I don’t really like, but it may be better than what Perl does – which is nothing).

Perl (5) is not a full OO programming language, just a procedural language that has got some additions to allow for OO dynamics, but still I'm surprised I can't "protect" object attributes... Getting back to Inside-Out Objects, the best analysis I’ve found is from perlmonks in 2005.

I agree with the points raised by jhedden (however I find points 1, 2, 3 and 9 “less strong” than the others):

1. Hash-based objects are the standard. Using a different object API may lead to maintainability issues.
2. Inside-out object classes aren't compatible with hash-based object classes.
3. Inside-out objects are just another kludge on top of Perl's already kludgy OO mechanisms.
4. I haven't had any problems using hash-based objects. The encapsulation and compile-time checking advantages of inside-out objects aren't important enough to induce me to use them.
5. The encapsulation provided by inside-out objects is unenforcable because the source code is available.
6. Inside-out objects require a DESTROY method, and I don't what to have to remember to write one each time I create an inside-out class.
7. There are too many alternative inside-out object support modules that aren't compatible with each other.
8. I'm leery of the 'magic' the inside-out object support modules do 'under the covers'. There may be bugs or they may lead to unexpected problems when interacting with other modules.
9. I tried module Foo::Bar, and had problems with it so I gave up on trying to use inside-out objects.
10. You can't serialize inside-out objects either in general, or using Data::Dumper or Storable.
11. Inside-out objects are not thread-safe because they usually use refaddr as the key for storing object data.

I was hoping perl 6 will eventually solve the problem of private attributes (which is all I want here) and it seems I’m lucky:

Attributes are defined with the has keyword, and are specified with a special syntax:

class MyClass {

has $!x;

has $!y;

}

The ! twigil specifies that this variable is an attribute on an object and not a regular variable.

Attributes are private, but you can easily add an accessor for it, that is a method of the same name that can be called from the outside of the class and returns the value of the attribute. These accessors are automatically generated for you if you declare the attribute with the . twigil instead:

class MyClass

has $.x;

has $.y;

}

When you assign to an attribute from within the class, you still have to use the ! form.

Do I like that syntax? I do not. Do that mechanism satisfy my need? Yes, thank you.

Another reason to look forward to Perl 6.