use Perl

• -apply_to( $obj )? (Score:1)

  by jjore (6662)

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

    by ChrisDolan (2855)

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

      by jjore (6662)

      It's also not reentrant since you're fiddling with a global.
      • Re: (Score:1)

        by ChrisDolan (2855)

        Good point.
• Changing my mind (Score:2)

  by Ovid (2709)

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

    by ChrisDolan (2855)

    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
• deja vu, kind of... (Score:2)

  by jhi (318)

  http://search.cpan.org/~jhi/Class-Privacy-0.03/lib/Class/Privacy.pm [cpan.org]
  • Re: (Score:1)

    by ChrisDolan (2855)

    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