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.

Devel::EnforceEncapsulation headed to CPAN 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • 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 needs to be, but I consider the protection of hash refs to be a similar scenario: a gesture toward encapsulation that only partially solves the problem. However, also like non-executable stacks, hash encapsulation is useful for finding cases where non-malicious code is violating convention.

      Like the Linux kernel and non-executable stacks, Perl objects may someday get good protection without the encumberance of inside-outness. But unless Class::Encapsulate takes off, that might have to wait for Perl 6.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.