Re^5: Closure objects with public, private, and protected fields

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.

Comment on Re^5: Closure objects with public, private, and protected fields

Replies are listed 'Best First'.
Re^6: Closure objects with public, private, and protected fields by adrianh (Chancellor) on Mar 09, 2006 at 10:44 UTC
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]

Replies are listed 'Best First'.

Re^6: Closure objects with public, private, and protected fields
by adrianh (Chancellor) on Mar 09, 2006 at 10:44 UTC

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]