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? 24 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I thought InsideOut objects was *the* thing to do in OO Perl now?
    • It was *A* thing for a while.

      Most of the noise was taking the idea and working out which implementations don't suck.

      • The implementation that doesn’t suck is called Hash::Util::FieldHash, courtesy of 5.10, coming to a CPAN near you soon.

  • It may be tricky to add that attribute, but once you do it will be, like, totally encapsulated...
  • 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
    • Agreed totally - it's trivial to avoid the problems that Object::Std and O::IO try to solve without all the extra nonsense, what's more you can still use a sensible class framework.

      Not once in the decade I've been writing Perl have I needed O::IO or it's ilk.
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
    • That solves only one of the two problems Inside-Out Objects try to solve.

      The other is turning (possibly hard to find) runtime errors into compile time errors.

      Preferring $hash -> {attr} (or $hash -> {__PACKAGE__} {attr}) over $attr {refaddr $ref} is, IMO, as sane as preferring package variable and 'no strict' over lexical variables and 'use strict'.

      Inside-Out Objects has never been about providing encapsulation with a shotgun. It simply favours perl5-style variables ('strict', 'lexical') over per

      • Yes, that's a very good point, and what I suggested doesn't address it at all. I wonder whether a bit of sugar around restricted hashes could provide something 80% as useful without many of the drawbacks of inside-out objects... but I haven't given it much thought, let alone experimentation.
        --
        rjbs
  • I'm disheartened to hear that you're having trouble with another programmer's code, and laying the blame solely on OIO. If you need help, OIO's POD references both the module's discussion forum [cpanforum.com] and the author's email: jdhedden AT cpan DOT org.

    While OIO's POD does discuss some of the advantages of using the inside-out object model, it also lists several more involved discussions on the matter including Damian Conway's book Perl Best Practices.

    OIO does provide methods for maintaining persistent data, bu

    • I was having problems with O:IO because of it's frankly bizarre idea of requiring a user to provide regexen to match method/attributes, not to mention it's abuse of attributes syntax (yummy - whitespace sensitive code for no good reason).

      The number of places where it was needlessly complex and required copy and pasting where any sensible Class framework allows you to just specify the columns and have it DTRT.

      "OIO does provide methods for maintaining persistent data, but not directly to a database. However,
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;

      • Errm, DBIx::Class is an object-relational mapper, not a class framework. Criticising Object::InsideOut for not being an ORM is like criticizing perl for not being an editor. What are you even talking about?

        • DBIx::Class is also a class framework, same as Class::DBI and Class::Accessor - all of which are much easier to use and maintain than O::IO.
          --

          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;

          • No, CDBI and DBIC are not the same kind of thing as Class::Accessor. You don’t write programs with CDBI/DBIC if they have nothing to do with a database, and you don’t stick non-database-related logic in your CDBI/DBIC classes either.

      • "requiring a user to provide regexen to match method/attributes"

        It's not a requirement - it's optional. Cut out the regexes, and your preformance will go up (probably significantly). The regex option is there to provide greater programming flexibility if that is desired. As with any feature, if it's not needed, then don't use it.

        "There is a great deal more to useful object persistence than a couple of SQL statements..."

        The requirement to tie your objects to a database was evidently something the or

        • Great :) I'd love to get rid of the regexen, but now they are there I don't know where they are used and would need to check - it looks to me that the original author cargo culted because the documentation wasn't clear enough - I certainly didn't find a nice simple example in the documentation.

          Class::Accessor and it's like allow me to specify my attributes in a single line, even Moose is less bizarre in how you specify attributes.

          I'm surprised people would choose to use O::IO in production code, I certainl
          --

          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.