|Perl: the Markov chain saw|
Re: characterstics of private in perlby demerphq (Chancellor)
|on Mar 09, 2003 at 10:58 UTC||Need Help??|
On the otherhand does perl by itself support private data members?
The short answer is no. The long answer is to read TheDamians book, and trawl the archives for the appropriate terms, but basically it comes down to, "you can make it tremendously difficult, but can never absolutely prevent it". (In fact I might argue that the same is true in C++)
But im betting that the answer doesn't matter, as the question is probably not relevent. Most people that come here asking for such things have programmed in Java or C++ a lot. They are used to obscuring things, partially to resolve common problems in these statically compiled langauges, partially because the language purists insist on using them, and partially because that was the way they were taught. Their mentality (for good reasons given the languages their experience is in) is to hide and protect and typecheck everything. In perl the mentality is different because the language is dynamic and because libraries are not compiled to an intermediate form, you always have the source code of what you call.
Consider some of the things that you can do in perl and youll soon stop worrying about private data: override keywords, dynamically override subs in other packages at run time, inspect the optree, deparse the optree, walk the private memory pads of the scopes in the program, inspect the stack at run time, etc.
As another poster said, perls motto is "don't enter my private spaces unless invited to do so" but theres an invisible caveat: "or you really need to". To take the living room metaphor, it doesnt matter what security we put on the door and windows, if the fire department wants to enter, then they will. :-) Likewise in perl, normally we dont muck about with the internals of objects unless we are the author, but occasionally you find a bug or a quirck that you need to fix. For one reason or another we cant just fix the source code that is broken (maybe cause its a shared library or something), so we inspect the source and contrive a workaround that involves utilizing "internal" information and twiddling. The harder that type of approach is the more annoyed we will be. OTOH, if we do it and get burned for some reason, its our problem, not yours. So dont worry about it.
The moral of this story is forget about private data for objects until you can explain in detail in perl why exactly you must have them. However im betting that a) it wont happen for quite a while, and b) once it does youll be able to figure out a perfectly feasable way to provide the extra level of "privacy" needed to resolve whatever issue you are having.
I wonder how long it will be until you start asking yourself, Why oh Why was so preoccupied about this in the first place?
Peeps, please dont reply with a bunch of examples of where private data is so useful or required in other languages. If you have a perl example fine. :-)