| [reply] |
Sure it is, but restricting access to code within a module means you've lost flexibility.
However, you do get both to some extent by using something like the _variable convention. You are told what you should be doing, but aren't forced to do it.
To me, that is sufficient idiot proofing. I don't think its in society's best interest to protect really determined idiots.
| [reply] |
However, you do get both to some extent by using something like the _variable convention. You are told what you should be doing, but aren't forced to do it.
But the problem is that some of these conventions, as well as allowing clever people to do clever things, mean that sensible people doing sensible things have problems.
For example if I add a _private_method to Foo module v1.01, and Sally already has a _private_method in her Foo v1.00 subclass then things will break for no good reason when Sally upgrades.
Should Sally have to go read the code before she can subclass a new version? When only "internal" APIs have changed?
Nobody is being idiotic here in my opinion. It's just Perl's broken OO encapsulation getting in the way of real work being done.
| [reply] |
Sure it sucks to have to fix someone else's code because they didn't read the documentation, but it also sucks to be physically restrained from doing something that is perfectly logical simply because the author of an object never conceived that you'd use his object in that particular way.
If you're clever enough to outhink the module author, surely you're clever enough to extend his module to cover your reasonable and well thought out usage pattern?
so in my book flexibility trumps idiot proofing
Flexiblity is comparatively easy; idiot proofing is very, very hard. ;-) Ask anyone who's tried to keep small children (or cats!) safe; it's harder than it sounds sometimes.
--
Ytrew | [reply] |