Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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.
In reply to Re: OOPerl isn't that bad after all...
by dws
|
|