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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday October 06, 2006
11:54 AM

Better Inside-Out Objects

[ #31241 ]

Wouldn't it be nice if inside-out objects worked like this?

use base 'Encapsulation';

sub new {
  bless {}, shift;
}

sub foo {
  my $self = shift;
  return $self->{foo} unless @_;
  $self->{foo} = shift;
}

1;

If that was the interface but subclasses and other code couldn't reach inside, wouldn't more people use 'em? I believe most programmers violate encapsulation because they're lazy, not because they've gone rogue or something. Here's how to make that work.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Better Inside-Out Objects 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • How about setting this at the top:

    BEGIN {
       if ($running_on_dev_server) {
          require base;
          base->import('Encapsulation');
       }
    }

    That gives you protection during testing/development and speed in production (at the risk of REALLY painful bugs if there are flaws in the emulation of Encapsulation.pm).

    Alternatively, change the "if" to

      if ($ENV{AUTHOR_TESTING}) {

    • No.

      Ovid is throwing away half the point of inside-out objects already: compile-time checking of field names. The other half is being agnostic about the implementation of any superclasses; and your suggestion would mean that one could no longer rely on that, either.

      You may as well not use inside-out objects at all. (I am reminded of chromatic’s chocolate cake recipe analogy…)

      • I was simply suggesting that this hack could be used at development time to catch places where external code illegitimately accessed variables via hash values instead of accessor functions.

        That is, the encapsulation hack could be put to an alternate use. Especially if the overload function dies if the caller package isn't isa('Encapsulation').

        I agree that the "inside-outness" is not significant in this case.

  • People seem to think that Inside-Out Objects are about not letting other people touch your internals.

    They aren't.

    Inside-Out Objects solve two out of three problems* I have with traditional Perl OO:

    • It's not benefitting from enabling 'strict' (that is, no compile time checking of attribute names). Now you may say "I don't care about that, I have tests", but that just means you find both 'use strict' and 'use warning' fluff - after all, you have your tests.
    • In an inheritance tree, your implemenation is

    • I've evidently been wrong about IOO. Since the major problem I've faced has traditionally been encapsulation, that was the bit I've focused on. I will have to concede all your points. I just find that virtually every IOO implementation I've seen out there has been painful to work with, so I gave up and hope that solving the major problem I have might be good enough.

      • Hmm. For me, the visible difference between hash-based and inside-out objects is turning the following:

        my $self = shift;
        $self->{ bar };

        into this:

        my $self = refaddr shift;
        $bar{ $self };

        That seems hardly painful… but then, as MJD says, people are weird about syntax.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.