Beefy Boxes and Bandwidth Generously Provided by pair Networks Frank
XP is just a number
 
PerlMonks  

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.


Comment on Re: Better Inside-Out Objects :)
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.

    -xdg

    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).

    Cheers,
    Ovid

    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?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://576792]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (7)
As of 2014-04-18 23:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (472 votes), past polls