Re: 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.

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.

Comment on Re: OOPerl isn't that bad after all... Select or Download Code

Replies are listed 'Best First'.
Re^2: OOPerl isn't that bad after all... by adrianh (Chancellor) on Oct 05, 2003 at 23:56 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^2: OOPerl isn't that bad after all...
by adrianh (Chancellor) on Oct 05, 2003 at 23:56 UTC

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.

[reply]