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

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. ;-)

---

Remember, when you stare long into the abyss, you could have been home eating ice cream.

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.

Or, more generally, you can't trust the people who'll be using the code to follow the guidelines you've laid down for them. And, with Perl, it's a bit harder to lay down guidelines; you have to trust that people will read your POD documentation.

If one could add and override functions in that class freely, that class would be useless.

Well, it may be useless in terms of what you originally intended, but they are trying to get some use out of it, or they wouldn't be bothering with subclassing your class. Do you want to let them follow their bliss, or use language features to block them?

Java (and I'll pick on Java since that's what I'm using most at the moment) has this problem big-time. The language lets a class author dictate how a class gets used. And if your intended use isn't quite what the author intended (which can happen if you have more imagination than they did, or if some new possibility emerges in the literature), guess which one of you is screwed? They didn't want their precious class modified, so they've declared member variables private, and member functions final, and you're stuck stuck stuck.

Well, it may be useless in terms of what you originally intended, but they are trying to get some use out of it, or they wouldn't be bothering with subclassing your class. Do you want to let them follow their bliss, or use language features to block them?

Not that I disagree with your comments about the Java fetish for the premature finalisation of interfaces, but I think that the point being made was that sometimes you need to block the users of a class. Occasionally you need to guarantee that one piece of code cannot get at another.

This is harder in Perl5 than it needs to be.

For example, I recently worked on a set of Template modules that could, potentially, have been used by a nasty template author to access elements of the model that the original author obviously didn't intend. Closing this security hole up was a surprising amount of work because of the large variety of ways Perl has of digging into structures. In Java a couple of "private" statements would have made the problem go away.

You want to take a look at Re: Tutorial: Introduction to Object-Oriented Programming and learn about "inside out objects", a technique that gives you all that Java and co do without taking away anything from the freedoms Perl grants. See also Class::InsideOut - yet another riff on inside out objects..

For total isolation, you can also have $self be a closure that carries the properties around as lexicals in its closed scope. It might accept the name of property as its first parameter; or do something else. With this approach, not even instance methods can bypass the encapsulation. This is not really a useful approach, though.

I used all of this features, and felt a sense of freedom that you only get with perl.

Actually you get it with lots of other languages too :-) Java is a very restrictive language (by design). Try playing with Self, Smalltalk, Ruby, Lisp, Python, etc. and you'll find lots of similar benefits.

Learn more languages. More languages good :-)

To demonstrate why this is important sometimes, think of Java's SecurityManager class: It controlls all activities in the JVM including file and inter-thread actions. If one could add and override functions in that class freely, that class would be useless.

Remember - this is only as secure as the JVM itself. If you can compromise this you don't have any real security.

Is there such a way?

You can use techniques like inside out objects, lexically scoped anonymous subroutines, etc. to get similar levels of encapsulation in Perl.

Are there any other downsides (and upsides) that I am not aware of?

Another downside is in creating extensible classes. It is easy to write a class in Perl that can be accidentally broken by a subclass, or have a sub-class that is broken by a private implementation change in a super class.

There are, of course, ways to code around this given sufficient discipline, but it's harder than it should be. As ever it looks like Perl 6 will solve all of these problems ;-)

Nice, dws. You read Joseph Campbell, I presume?

The impression I get from the Java community is that it has no interest in becoming part of the open source community. The language's debut as a way to deliver user-safe code, keep the source obfuscated, and the back-end apps private just shouted privacy, security, proprietary, etc.

The Perl community seems, from my limited experience, to be more about being open, peer review, solving the problem, etc. Security concerns are more about preventing web users from hacking your database or doing the root dance on you.

The thinking of the communities is different, and so the evolution of the languages. I don't want Perl to have the same features, cool though they might be, as a proprietary, closed, secretive language. If nothing else, that will attract the wrong kind of thinking to us, tainting our kernel, so to speak.

I see two lines of thought here. The first can be represented by:

"Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

Which means - since the source is open anyway there's no point in securing the code itself but rather the machine that runs it. That I am happy agree with. On the other hand, I also see this line of thought:

"The only way to secure your computer is to remove drives and weld the case."

This is something I once saw in a discussion about securing desktop PCs from tampering, where somebody commented that usernames and passwords are a waste because "I could always go to that PC and boot it with Knoppix". Yes, he could. If one is determined enough, he can crack into almost anything. Will that make anyone take less care of security? So the comments like "Java programmers just think their code cannot be decompiled" are a bit like saying "weld your case". If you have the time and patience, you can disassemble even a binary file and learn how it works. Most people (and the average script-kiddie) won't, though - at least that's what seems right to me.

Regarding inside-out objects - very nice. Reminds me of the old days, before OOP, where if your program had three veteran soldiers, you'll have 3 places in the num_limbs array, 3 places in the medals array, etc. That's doing OO without too much fancy OO syntax, but also without too much hassle.

PS - off topic: It's Yom Kippur here in Israel, a day that is devoted to contemplating our sins and mistakes in the now-ending jewish year, and a time of asking and giving forgiveness and making peace with each other. So - I sincerely apologize for any post that was too much off topic or too stupid, for posts where I said wrong things, etc.

I used to worry about this sort of thing all the time. Really it would keep me awake at night. Then I ditched Windows, and switched to Unix. Fairly soon I stopped worrying. I'm not trying to start an OS holy war here - hell, I've no idea about what your favourite Desktop OS is (but I'm guessing Windows). But there is definately some sort of culture thing going on which I only became aware of when I switched.

With windows I suppose it can be best summed up as "maintain control" - and is the responsibility of the creator of the code. Whereas with Unix it's more like "best practice" - and is the responsibility of the user of the code.

I'm a fan of "best practice". It seems like it's less work when I'm hacking code. I also like the possibility of stepping outside the envelope if I wish - although I've learned that's usually not a good idea. But the main reason is that I don't need to write decent API documentation... read the code POD if you really want to know.

The source being available is no reason not to write documentation. If everyone had to read the glibc and Linux kernel sources to write programs for Linux, we'd never have gotten anywhere.

Documentation is like sex — when it's good, it's very good, and when it's bad, it's still better than nothing.

The fact that POD makes it particularly easy to document means you really have no excuse not to write documentation. Imagine CPAN without POD, and half the modules without documentation: sure, there's all this great code out there, but if you want to know what it does you have to download and unpack it, and if there's no docs, read the source. How much use would such a repository be?

One thing that's cool about the hacker culture, however, is that even if you only wrote very sparse docs to begin with, if there's a lot of interest in your code it's likely that others will contribute documentation. They can also spot documentation errors for you, because they can read the source. Just remember that without any docs, it's not likely that anyone else will get interested. Make it habit to slap at least some basic POD onto your Perl code.

Makeshifts last the longest.

The source being available is no reason not to write documentation. - True. Doesn't stop me from being lazy.

The fact that POD makes it particularly easy to document... - I'd forgotten about POD, it's so much part of my perl, it is perl.

I should also add that even if you don't plan to release your code, writing some documentation is "best practice", it will save hours of irrtation when you need to hack some of your old code.

--
TTFN, FNORD

xaphod