Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: characterstics of private in perl

by demerphq (Chancellor)
on Mar 09, 2003 at 10:58 UTC ( #241540=note: print w/ replies, xml ) Need Help??


in reply to characterstics of private in perl

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. :-)


---
demerphq



Comment on Re: characterstics of private in perl
Download Code
Re^2: characterstics of private in perl
by adrianh (Chancellor) on Mar 09, 2003 at 12:03 UTC
    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++)

    I would say the short answer is yes, and the long answer is the same. Closures and inside-out objects are just as "private" as C++ private vars.

    But im betting that the answer doesn't matter, as the question is probably not relevent.

    The questions is very relevant. Good encapsulation is necessary to produce solid libaries without hidden dependencies.

    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. :-)

    Okay :-)

    Consider a generic module LazyObject for lazy loading. A naive implementation might include a method like this:

    sub load { my $self = shift; return unless $self->{_loaded}; # load lazy object $self->{_loaded}=1; };

    Consider something that inherits from LazyObject:

    package Weapon; use base qw(LazyObject); # add ammunition to weapon sub load { my ($self, $ammo); $self->{_loaded} = $ammo; }; sub can_fire { $self->{_loaded} && $self->{_working}; };

    Oops. Clash of private object attributes. If you are the author of both modules, it is an easy fix. If you are not - if LazyObject is something from CPAN intended to be generic - it's harder.

    Now, what are the options:

    • As the author of Weapon I can go read the source for LazyObject, figure out that there is a naming clash and change the names of the Weapon attributes. A pain the ass, and I open myself to possible future problems if LazyObject changes the names of it's private methods/attributes to match mine.
    • As the author of LazyObject I can document my private methods/attributes so users of the module can avoid them. This somewhat defeats the object of using private methods/attributes - and there is still the problem of adding new private methods/attributes in a later version breaking the code of people who inherit from LazyObject.

    The ability to have private attributes make the problem disappear. Both module authors can have whatever private variables they consider necessary without having to worry about each other.

    The issue is encapsulation not data-hiding.

    The "shotgun" analogy is a false one in many cases. The problem here is not deliberate invasion, it's accidental trespass. As the author of LazyObject I don't care if an author deliberately goes in and messes with _loaded. The problem is with somebody accidentally overriding it because they don't know it's been used. The fact that I can break other peoples code by adding another private attribute to a new version of LazyObject is terrible!

    This kind of mess makes writing bullet proof modules for reuse much harder than it needs to be. Personally, I don't think "reading the source" is a solution. I shouldn't have to read the source of another module to get my one to work. That is what encapsulation and abstraction is all about :-)

    Now, there are many ways around this (closures and inside-out objects for example). However, they all involve extra work. So I am really looking forward to perl6 and decent encapsulation.

      I would say the short answer is yes, and the long answer is the same. Closures and inside-out objects are just as "private" as C++ private vars.

      Well, my understanding of the above is that with sufficient trickery the data isnt really private. But I also agree that they are more or less equivelently private as compared to other things. I just dont agree that there is really a need for them in most cases.

      The questions is very relevant. Good encapsulation is necessary to produce solid libaries without hidden dependencies.

      The way I see it the question "How do I do private object attributes" is not the same as "How to I avoid object attribute namespace clashes in inheritance". I would say that the first is just one answer to the second, the one that in many ways is the simplest to implement and may have certain interesting properties, but not the only nor necessarily the best answer by any means.

      Now, what are the options:

      Well I can think of bunch of options besides closures/inside out objects. The most immediate strategy I would take would be to use a single, package specific key, then put all my attributes under that. If one day the original object was changed to have a key for its own use with the name of my package, well then I would be suprised.

      To me the point is this, if an author wishes to create a class that is intended to be used as a baseclass he had better take care to organize the object in such a way that this isnt a problem. This could be something like this code

      We have now have more or less addressed the real problem that you wanted solved, and without introducing privacy. We can call package_attrs with a package name to twiddle their attributes if we want to, and we probably won't do so accidentally.

      I agree that in some ways its too bad that there isn't a clearly defined framework that we can all be comfortable within, and its good that Perl6 will address that. I just dont agree that there is no other way than introducing purely private variables.

      I agree that designing an OO framework with heavy use of inheritance in mind requires a bit of effort. But usually you only have to do it for the base class and then its not that much effort to use.


      ---
      demerphq


        Well, my understanding of the above is that with sufficient trickery the data isnt really private. But I also agree that they are more or less equivelently private as compared to other things.

        I agree - what I was trying to say that the C++ "private" variables are not really private either. We can always just treat the object as a sequence of bytes and get at them that way.

        The way I see it the question "How do I do private object attributes" is not the same as "How to I avoid object attribute namespace clashes in inheritance". I would say that the first is just one answer to the second, the one that in many ways is the simplest to implement and may have certain interesting properties, but not the only nor necessarily the best answer by any means.

        I agree they are not the only answer - but they are an answer. A nice simple answer in my opinion. I was providing one example of where private object attributes would be useful in perl - which was your request ;-)

        With the exception of inside-out objects and closures the problem with other solutions, including package specific keys, is that they rely on the sub-class writer being aware of the mechanism for you to be completely safe. For me "more or less" and "probably won't" isn't good enough.

        That probably says something very sad about my personality :-)

        As you say, you can get around the problems with a bit of effort. However, the effort is enough that people get it wrong. I resent having to code stuff that the language should take care of for me. This stuff should be simple. Roll on perl6!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://241540]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2014-08-30 06:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (291 votes), past polls