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.

Object::InsideOut - why on earth use it? 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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

    • avoiding tight coupling can be reduced to a cultural problem

      I suppose Ruby-community-style monkeypatching is OK with you too?

      • 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
        • ...and what the heck is monkeypatching?
          • 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

            --
            rjbs
            • 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.

              • 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

                • 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

        • 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 fo

          • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.