use Perl

• cultural solutions (Score:1)

  by rjbs (4671)

  Inside-out objects are really neat and cool. That's why I don't think I will use them.
  
  There are definite benefits, like improved encapsulation, but I don't need a shotgun -- especially one that has lots of overhead costs. In Perl, avoiding tight coupling can be reduced to a cultural problem, in my experience.
  
  Sometimes, I use a pattern like this:
  
      $object->{__PACKAGE__}{attr} = $value;
  
  Now the object's guts are well divided into areas of authority. If you, Subclass::Happy start screwing aro

  --
  rjbs
  • Re: (Score:1)

    by Aristotle (5147)

    avoiding tight coupling can be reduced to a cultural problem

    I suppose Ruby-community-style monkeypatching is OK with you too?
    • Re: (Score:1)

      by rjbs (4671)

      What the hell is that supposed to mean? I said that you should avoid tight coupling and screwing around in the guts of objects you don't destroy, but that the solution of inside-out objects can be a greater cost than is needed if you can effect a cultural solution.
      
      How is that an endorsement of anything even remotely like monkeypatching?

      --
      rjbs
      • Re:cultural solutions (Score:1)

        by Aristotle (5147) <pagaltzis@gmx.de> on 2007.11.27 11:41 (#59193) Homepage Journal

        You made an unqualified claim that inside-out objects have some unspecified overhead cost and then said the absence of their benefits is only a problem if you make it one. That’s the same sort of argument by which monkeypatching gets justified – “it’s only a problem in practice if you make it one, and doing it this way is easier.” I cringe in embarrassment whenever Perl hackers trot out the living-room-and-shotgun line in the presence of others (and when it’s just Perl folk I roll my eyes).

        What are those rumoured costs anyway? The only ones I’m aware of are second-order effects of DESTROY being broken and threads being terrible in Perl. Thankfully, 5.10 hacks around both of these. (Well, personally I don’t care about threads, so that one doesn’t affect me in any case.) Is there any counterargument if 5.10 is presumed?

        Reply to This

        Parent

        • Re: (Score:1)

          by rjbs (4671)

          You made an unqualified claim that inside-out objects have some unspecified overhead cost and then said the absence of their benefits is only a problem if you make it one. That’s the same sort of argument by which monkeypatching gets justified – “it’s only a problem in practice if you make it one, and doing it this way is easier.” I cringe in embarrassment whenever Perl hackers trot out the living-room-and-shotgun line in the presence of others (and when it’s just Perl folk I roll my eyes).

          I must not have been clear enough. I will be very plainspoken and see if that helps me communicate any better: It is always a bad practice to alter an objects behavior without limiting the scope of those modifications. It is also always a bad practice to alter the data associated with an object without controlling the way that the object 's methods and its data interact. Unfortunately, it is difficult to do this in Perl. One solution is inside-out objects, which prevent the user from altering an objec

          --
          rjbs