use Perl

• Dev vs. live (Score:1)

  by ChrisDolan (2855)

  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}) {
  • Re: (Score:1)

    by Aristotle (5147)

    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…)
    • Re: (Score:1)

      by ChrisDolan (2855)

      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.
• That's not what I call 'inside-out' objects. (Score:1)

  by Abigail (26)

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

    by Ovid (2709)

    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.
    • Re: (Score:1)

      by Aristotle (5147)

      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.