Re: OOPerl isn't that bad after all...

[demerphq]

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

[idsfa]

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.

Nothing is unviewable (JODE). Java programmers just think that their code cannot be decompiled and modified. This leads to the culture which demerphq described. Perl grants no such illusions.

Now, if you wanted to implement some sort of immutable perl class, you'd probably need to go the Module::Signature route. You still don't have totalitarian control, but at least you can disown the modified classes. Which is actually the way it's done in java ... hey, maybe there isn't MTOWTDI. ;-)

[adrianh]

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.

There's also the major problem that Safe isn't very... well... safe. There have been numerous exploits (e.g. CAN-2002-1323) and it's not really comparable to the Java sandbox IMHO.

Dealing with untrustworthy code is a real problem for some applications, and it is a pity that it is a hard problem in Perl. I recall seeing some comments that they'll be some form of decent sandboxing with Parrot so this should be able to be done nicely in Perl 6.

On a brighter note Perl does deal with untrustworthy data very well - using its taint mechanism. Something that is much harder to do in Java.