characterstics of private in perl

[Anonymous Monk]

Hi
I am trying to see how the concepts of private in C++ class holds true in Perl. Basically I see that for "methods" in class, Perl as such doesn't support private characterstics however you could use perl constructs to do it.
On the otherhand does perl by itself support private data members?

[Cabrion]

does perl by itself support private data members

No. As paraphrased from Perl's documents, Larry Wall or somone says . . .

Perl objects take a unique approach. Object attributes & methods are private because they asked you not to come into their living room, not because they have a shotgun.

However, there is a convention that many modules use. Typically "private" object attributes and methods are prepended with an underscore. This doesn't force them to be private, but it serves as a signal to let other developers know they shouldn't be tinkering with them.

[tachyon]

Ah no actually. As we all know Perl can do anything. You CAN make stuff completely private in Perl. See Re: characterstics of private in perl. In the sub set_count() add a warn if you want a BB gun, a die if you want a shotgun or, if you want a nuke, you could even make that fork while 1 ;-)

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[demerphq]

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

[adrianh]

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.

[demerphq]

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

Read more... (2 kB)

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

[graff]

While this is not something I've had much (any) personal practice with, I recall from reading about it, in Damian's excellent book (Object Oriented Perl, esp. chapter 11), that you can effectively "hide" object data by using closures; e.g.:

{
   my $object_data;

   sub _get_data {
       return $object_data;
   }
}

The "_get_data()" sub can be called by various methods defined elsewhere in this object's package, and when it's called, the content of $object_data will be returned. But that scalar variable is out of scope, hence inaccessible, for everything but "_get_data()".

[tachyon]

You want to buy The Damian == 'Damian Conway' book on Object Oriented Perl - Google for same. Damian is a Perl guru and comes from C++ Here is short closure example of a private var, and private func:

# here $count and $private_func are undef
# add_to_count() sub_from_count() get_count() set_count() and widget()
# are the only ways to access $count and ($)private_func()

{
    # use a closure to keep peoples sticky fingers off $count
    my $count;

    # define a func totally private to this closure
    my $private_func = sub { [blah blah blah] }

    # now here are a couple of modifiers
    sub add_to_count { 
        ++$count 
    }
    sub sub_from_count { 
        --$count 
    }

    # and the usual couple of accessors....
    sub get_count { 
        $count 
    }
    sub set_count {
        my ($new_count, $user ) = @_;
        if ( $user = 'root' ) {    # OK, OK so it is a silly example!
            $count = $new_count;
          return $count;
        }
        else {
            warn "Only root can set count directly, use add/sub/get bl
+ah..."
          return undef;
        }
    }

    # and something silly to use our private func...
    sub widget {
        &$private_func(@_) if $moon_in_venus && $believe_that_sort of 
+stuff;
    }
}

# here $count and $private_func are undef

This shows you how to make a private var and use it but you can make private funcs as well using the syntax shown. Only stuff in the closure (block) can use it using syntax &$privat_func(@args). Note a perl func returns the last val evaluated so you can often neglect the return as it is imlicit.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[Hofmator]

You want to buy TheDamian

I know that he's looking for a job but I didn't know that he was for sale ...

;-)) scnr

-- Hofmator

[adrianh]

You can create private object attributes using Abigail-II's inside-out objects technique.

[bronto]

Check Attribute::Protected

Ciao!
--bronto

---

The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
--John M. Dlugosz

[tachyon]

As we all know Perl can do anything! See this.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[Cabrion]

Just because you can doesn't make it a good idea. I have no doubt Larry et. al. put a great deal of thought into giving Perl the magic power of private memebers in a more straight forward manner. The fact that they chose not to, and the fact that they are far smarter than I, tells me there is a reason to not write contorted privacy code in the general case. I think that's what the OP was asking.

he, he . . I said member.

[adrianh]

Just because you cannot do something doesn't mean it's a bad idea :-) Did the fact that perl4 didn't have lexical variables or OO mean they were a bad ideas?

There are good reasons for proper encapsulation. The only reason "privacy" code is contorted in perl5 is because perl5 doesn't provide the necessary functionality. Writing OO code in perl4 was "contorted" too ;-).

You can do private methods and object attributes in various evil hacky ways in perl5. Sometimes this is necessary. Fortunately perl is an evolving language and, from what I understand, you will be able to do it nicely in perl6.