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.

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