Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • People seem to think that Inside-Out Objects are about not letting other people touch your internals.

    They aren't.

    Inside-Out Objects solve two out of three problems* I have with traditional Perl OO:

    • It's not benefitting from enabling 'strict' (that is, no compile time checking of attribute names). Now you may say "I don't care about that, I have tests", but that just means you find both 'use strict' and 'use warning' fluff - after all, you have your tests.
    • In an inheritance tree, your implemenation is restricted by the implementation of the classes you inherite, and your implementation restricts the implementation of the classes that inherit from you.

    The first point means that OO programming isn't much better than programming in perl4 (not only don't you have the benefits of compile time errors, you don't have name spaces either).

    The second point means that Perl is making easy things hard: code reuse is much harder that it should be.

    The point of IOO isn't so much that it prevents other classes from accessing the internals (if you want to, changing a few 'my's to 'our's gives access, without giving up any of the other benefits of IOO), it's about giving classes the freedom to do whatever they want, without accidently touching someone elses internals.

    The implementation you suggest doesn't solve any of the problems IOO solves. You don't get compile time errors on mistyping attribute names, and you will put a dependency in the inheritance tree.

    Now, I won't judge your implementation as good or bad - if it works for you then it should be good enough, if it works for others so much the better. Just don't call it a different way of doing Inside-Out Objects. They aren't.

    *: The third point being: too much typing to get to an attribute.

    • I've evidently been wrong about IOO. Since the major problem I've faced has traditionally been encapsulation, that was the bit I've focused on. I will have to concede all your points. I just find that virtually every IOO implementation I've seen out there has been painful to work with, so I gave up and hope that solving the major problem I have might be good enough.

      • Hmm. For me, the visible difference between hash-based and inside-out objects is turning the following:

        my $self = shift;
        $self->{ bar };

        into this:

        my $self = refaddr shift;
        $bar{ $self };

        That seems hardly painful… but then, as MJD says, people are weird about syntax.