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.
 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
        • 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 object's data easily. However, inside-out objects have costs. These costs are added complexity due to garbage collection, threading problems, and difficulty when serializing. These problems may be mitigated by using an inside-out object framework, but then the framework itself is a cost. One of these frameworks is very simple fieldhash system in perl 5.10. Unfortunately, it requires perl 5.10, which has not yet been released as a stable product, and which will take time before it is deployed into vendor perls.

            So, if it is possible to create a *cultural* solution by having coding rules that ban unjustified alteration of foreign objects, this may be preferable to inside-out objects. The shotgun analogy is correct, here. Perl does not come equipped with a shotgun (encapsulation), so manners may have to do. Trying to bolt the shotgun on can prove more dangerous (to maintainability) than simply behaving well.

            The shotgun metaphor need not be a reason to never *add* a native shotgun. I like field hashes, and I think they are a good step toward correcting the errors in language design that have made encapsulation in Perl objects problematic. I am certainly more likely to use fieldhashes for encapsulated data than I am to use Class::InsideOut or Object::InsideOut.

            Abigail's point about compile time errors versus runtime errors was an excellent one, and I don't mean to address it at all, above.
            --
            rjbs