in reply to OOPerl isn't that bad after all...
I think there is an issue of security: You can't trust your class to be used the way you want it to.
...
think of Java's SecurityManager class: It controlls all activities in the JVM including file and inter-thread actions.
This to me sounds like an object oriented Safe compartment. In a safe compartment only certain ops can be executed. Its not commonly used IMO because running untrusted code isnt much of an issue in Perl.
I don't know of any perlish way to totally encapsulate your classes to be unpenetrateable..
I think you are mixing things up here. Security is not necessarily a virtue provided by an OO framework. Class and data encapsulation is not security. The concepts are orthagonal. In Java it looks like they are integrated, but I suspect that this is a consequence of a different design objective. Since Java programs and libraries can be delivered in a precompiled essentially unreviewable form there needs to be a way to control what they do on your system from the outside. With Perl however its extremely unusual to deal with untrusted code (ok not everybody checks the stuff they install from CPAN.) You always have it to read before you use it if you want.
This aspect of perl, that you always have the source, has a subtle effect on Perls overall mentality. We dont like making our programming life difficult. If you put checks in your code to block some scenario that you didn't like but I thought was reasonable then I can just change your code. Of course i'd rather you dont do this. Its much easier to extend your work, or adapt it for some unforseen use if you havent gone out of your way to make your code a fortress. A fortress that needs to be patched to be useful outside of the limits of your imagination. My imagination may be different. :-)
Now the typical response in this ritual (and its a common one especially from programmers in the Java comunity, do a Super Search) is that what you really are worrying is about you yourself doing dumb things accidentally. Well, Perl will kindly warn you when evil things like this happen (Subroutine foo redefined). If you are really worried about breaches of the object data encapsulation you can use techniques like Inside Out Objects or blessed coderefs to keep your data behind a virtually unpenetrable lexical wall. But I personally dont see much point, and consider such code less desirable just due to difficulties extendeding it.
Basically it comes down to this. If I want to use your module in way you dont want me to then thats not your problem. If you want to run untrusted code, use a Safe compartment. If you dont like people being able to use your code in a way you didn't intend, get out of programming. ;-)
So ultimately, just relax man, dont worry about it. Its not such a big problem as some people think. And when it does become a problem there are a whole slew of ways to deal with it. Ones that will allow you the appropriate protection that you need depending on the situation. Have a gander at theDamians book on OO programming he covers a variety of techniques including Tie::SecureHash
HTH
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Re: OOPerl isn't that bad after all...
by idsfa (Vicar) on Oct 04, 2003 at 17:33 UTC | |
Re: Re: OOPerl isn't that bad after all...
by adrianh (Chancellor) on Oct 05, 2003 at 23:03 UTC |