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: (Score:2)

        by lachoy (1663)

        ...and what the heck is monkeypatching?
        • Re:cultural solutions (Score:1)

          by rjbs (4671) on 2007.11.27 10:21 (#59190) Homepage Journal

          In Perl, it would be this:

          use File::Spec;
          use Other::Modules::Also;
           
          sub File::Spec::catdir {
            shift;
            return join('//', @_);
          }
           
          do_stuff;
          ...
          my $path = File::Spec->catdir(@parts);
          ...
          do_things;

          In other words: change the behavior of shared code by messing about with its guts, rather than by producing a subclass that you use. It's fast and easy (so a monkey can do it), acts like you've patched the source, and affects all the other code you've loaded and probably not reviewed for how it will be affected by your change. Oops!

          --
          rjbs

          Reply to This

          Parent

          • Re: (Score:2)

            by lachoy (1663)

            I think calling it 'monkeypatching' might be doing it an injustice. It's not pretty, but it's also something that (IMO) is useful when you know what you're doing, kind of like mucking with symbol tables. But it sounded from Aristotle's comment that this is SOP for Ruby folks, which I agree is scary.
            • Re: (Score:1)

              by Aristotle (5147)

              I agree it can be useful in limited and highly constrained circumstances. It has its place, much like GOTO, which I am fond of defending against dogmatists despite the fact that I practically never use it.

              The most common form among Ruby folk is adding methods to classes you don’t own. That does indeed seem to be SOP. Eg. Rake (the build system written in Ruby) stuffs a kitchen sink of filesystem-related methods into Object. Changing existing behaviour is less common, but they do that too; cf. the Ch
              • Re: (Score:1)

                by rjbs (4671)

                What's worse is the use of it in JavaScript. For example:

                Array.prototype.dump_it = function () { ... }

                That doesn't seem so bad except that because of the way the for/in operation works in JavaScript, this is now broken:

                for (i in some_array) { ... }

                It will now loop over: 0, 1, 2, 3, dump_it.
                
                Oops.

                --
                rjbs