Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Better Inside-Out Objects :)

by dws (Chancellor)
on Oct 07, 2006 at 04:02 UTC ( #576792=note: print w/replies, xml ) Need Help??

in reply to Better Inside-Out Objects :)

I've been puzzled by Inside-Out Objects. They've attracted a following, but they seem like a complicated, long-winded way of solving a problem that I don't have. You lose serialization. You lose some ease in debugging. And you gain what? Better support for data encapsulation? I can achieve the same--and I've seen a team achieve the same--with a coding guideline that says "don't peek or poke at someone else's internals unless it's really O.K." and the discipline to follow the guideline.

Replies are listed 'Best First'.
Re^2: Better Inside-Out Objects :)
by xdg (Monsignor) on Oct 07, 2006 at 12:00 UTC

    One of the big things you gain is orthogonal property storage and "black box" inheritance. With inside-out objects, you can subclass any other class regardless of the type of blessed reference (even if it changes in the future). In addition, you can freely add a private "_foo" property without regard for whether any super or subclass might now or in the future have a "_foo" property. This is a benefit if you (or your team) doesn't necessarily control every class in the class hierarchy. E.g. CPAN. This flexibility has substantial value for some people.

    (Of course, some implementations of inside-out objects choose to make this difficult in order to provide other features.)

    For more on the pros and cons of inside-out objects, see my YAPC::NA presentation: Eversion 101. I think it's a fairly balanced perspective on what people get and what the complexity is.

    I'm not an advocate, but I do think there's a lot of misinformation out there.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re^2: Better Inside-Out Objects :)
by Ovid (Cardinal) on Oct 07, 2006 at 16:24 UTC

    That coding guideline is the problem I have faced quite a bit. Working with teams of developers who don't appreciate the merits of encapsulation sometimes means adopting a different strategy. As a result, I've reluctantly concluded the sometimes one has no choice but to try a different way. Additionally, I've found myself violating encapsulation at times when it's innapropriate (I know some will disagree, but derived classes shouldn't be looking at their parent's privates).

    It's been pointed out that this strategy is essentially "use strict 'encapsulation'" and frankly, I'm happy with that as it solves the problem I wanted solved. Plus, when you're ready to move into production, if it's done properly, you can remove the encapsulation and everything still works (or you can leave it in if performance is not a problem).


    New address of my CGI Course.

      Working with teams of developers who don't appreciate ...

      That gets to the core of one of the problems I'm having with Inside-Out Objects. At one level, they're an attempt to apply a technical solution to a people problem. Sometimes that works, but other times, it just adds weight to the burden the project has to bear.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://576792]
[Discipulus]: i have a different opinion: automation is always worth: first i can use Perl (and this is good), then later you can reuse parts to automate others tasks. My $boss everytime say:'how much time you spend doing this?' So generally i present a perl solution
[Corion]: Discipulus: Yes, but the chart gives some limits on whether it's really worth spending time for saving your time. If you gain enjoyment, automating is still great, but it doesn't save time ;)
[Discipulus]: Corion are you would able to realize such thing? O_O
[Corion]: In the same vein I have a script that automates Firefox to enter some data into another system. It's not faster than the people using the script if they were to do it manually, but they prefer not having to check the data and not having typos when ...
[Corion]: ... entering the data
[Corion]: Discipulus: I don't know whether I could really do that, but the init process itself mostly launches other processes, and the whole startup is just following a path of dependencies and making sure they are all running. Which basically is what ...
[Discipulus]: when at work my time is (temporarly) owned by the firm, so i do not care (coworkers whatch movies.. I code Perl)
[Corion]: ... make already does, except for files instead of programs. But maybe with some /proc hackery, that could be eliminated and one could use plain make :-D
[choroba]: systemd just makes is asynchronous
[choroba]: so, make -j

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2017-07-27 09:28 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (408 votes). Check out past polls.