Re: Private Methods Meditation

A fair degree of privacy is gotten by constructions like you discuss. You have very well described the use of closures for private data and methods.

What I really applaud is your conclusion. Perl is not an enforced OO language. Like C++, it is a mixed language with support for OO but no requirement. Unlike C++, perl's OO constructs get by with conventions about what methods may be called reliably. We name private methods with a leading underscore, and we don't care what happens to people who call them from outside.

This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists, but it leaves a lot of space for us to work in. Mixed model languages are so much more comfortable to work in. The design of a program does not have to be pounded into any One True Shape.

After Compline,
Zaxo

Comment on Re: Private Methods Meditation

Replies are listed 'Best First'.
Re^2: Private Methods Meditation by BUU (Prior) on Jul 19, 2004 at 07:00 UTC
I often hear perl programmers say stuff like " We name private methods with a leading underscore, and we don't care what happens to people who call them from outside." and other stuff relating to not enforcing privateness in objects. I used to think this was a good thing, a benefit of perl, after all, if he really wants to do that, shouldn't he be able? Thats completely missing the point though. The point of private methods and data isn't to enforce your "one true shape" on any programmer that tries to use it, the point is so that you can inherit from it without worrying about what the hell your parent class did. Perl's object instance data is the main part that suffers from lack of privateness, anything you do in the child class with specifically affect the parent class, so if you want to use a specific key in your child hash, you'd better hope the parent doesn't, at any time, want to use this key! Sure theres some work arounds, but this is perl, we aren't supposed to have to take the long, unwieldy, verbose way to do stuff. It's supposed to be short, succint and to do what we mean.	[reply]
Re^2: Private Methods Meditation by stvn (Monsignor) on Jul 19, 2004 at 14:22 UTC
This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists, but it leaves a lot of space for us to work in. Most versions of Smalltalk do not actually have any notions of public/private/protected in the way Java/C++ does. Instead Smalltalk's notion of private methods is very similar to perl's, "If you weren't invited, don't come in". Smalltalk has things called method categories, which in the language are really are nothing more than syntactic sugar, but when you combine it with the Smalltalk environment, in particular the Smalltalk code browser, you have another layer of organization between the class-level and method-level. Typically Smalltalk programmers will put all their private methods into the "Private" category. Some Smalltalk implementations will complain (the equivalent of `warn`) when you call a method that is prefixed with an _ from outside of your class, but none (at least that I know of) will actually *enforce* this and not let you compile your code. Here is a link that goes into more detail if you are intetested. -stvn	[reply] [d/l]
Re^2: Private Methods Meditation by dws (Chancellor) on Jul 19, 2004 at 16:17 UTC
This voluntary cooperative model of OO gives the screaming horrors to Smalltalkers and other purists ... I assume that was meant in jest. This Smalltalker is not especially bothered by voluntary cooperation. I'd rather enable than restrict.	[reply]


Perl: the Markov chain saw
	PerlMonks