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.
  • Have you considered applying this directly to objects? Use Symbol::gensym to get a new package, make the object ISA the new class. Potentially you have to rebless the object higher or something. I'm guessing chromatic and Ovid did something similar with Class::Trait.
    • That's possible. Another way is simply:

          Devel::EnforceEncapsulation->apply_to($pkg);
          my $obj = $pkg->new();
          Devel::EnforceEncapsulation->remove_from($pkg);

      The instance keeps the overload, but subsequent instantiations are not affected. The only downside to that approach is that it might blow away any deref overloads that may exist in $pkg. But that's a pretty small hazard.
  • After giving it a lot of thought, I'm thinking now that Class::Encapsulate might seem like a good idea, but it's probably more trouble than it's worth. I think that your plan of applying it at runtime for development is probably a cleaner way to go.

    • I appreciate that. In our discussions, I've been frequently reminded of Linus Torvalds' opinion [lwn.net] on hacks to protect the Linux userspace from stack smashing exploits:

      "In short, anybody who thinks that the non-executable stack gives them any real security is very very much living in a dream world. It may catch a few attacks for old binaries that have security problems, but the basic problem is that the binaries allow you to overwrite their stacks."

      In typical Linus style that statement is harsher than it need

    • Wow, that's very similar! I had done some searches for "overload" and "'%{}'" before writing mine and your module did not show up.

      The key difference between our implementations are:
        * Mine applies externally post-facto, yours from inside the code
        * Mine allows access from sub/superclasses, yours does not (deliberately!)
        * Mine supports all of overload.pm's dereferencers, yours supports %,@,$, and &.
        * Mine allows access from anything in the same package, yours allows access