There are a couple of advantages to doing it that way:

• Methods have a nice inheritance mechanism, properties don't.
• Method implementations can be changed, but properties have to stay the same to be compatible.
• It's usually easier to think up an interface using methods, and then worry about implementing them. In my experience, this makes for a much more useful object design too.

By the way, it is very likely that your 'private' properties are accessible by other code. Don't worry about it, just don't document it.

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]

my $cgi = CGI->new;

my $template-adduser = HTML::Template->new(filename => 'new_user_form.
+tmpl');

my $template-deluser = HTML::Template->new(filename => 'del_user_form.
+tmpl');
[download]

The best thing to do is create a accessor and mutator method (or one combined method as seen often in Perl modules) for each of your properties. Users of your objects can only use these to access the property, then you're able to name them whatever you like.

Using a module to automate this is highly recommended. I'm partial to Class::Accessor just because it's focused and simple, but Class::MethodMaker does this and much more. If you'd like to learn, do it yourself using AUTOLOAD :-)

Chris
M-x auto-bs-mode

The best thing to do is create a accessor and mutator method (or one combined method as seen often in Perl modules) for each of your properties. Users of your objects can only use these to access the property, then you're able to name them whatever you like.

Eh, no. The root of all evil is that there's just one instance variable per object, and that all classes need to stuff their properties in it somehow.

Sure, you can make accessors:

    sub oogle {
        my $self = shift;
        $self -> {oogle} = shift;
        # Mark it as very, very, very, do not touch at all private:  
        $self -> {_________________furble} ++;
    }
[download]

But if 10 levels up in the inheritance tree there is an accessor

    sub habar {
        my $self = shift;
        $self -> {_________________furble} = 0;
    }
[download]

You are still in deep shit. No matter how many underscores you use.

Perls OO model was broken when it was designed. As I said at YAPC It sucks (to which Larry replied "I'm working on it"). Using Perl OO is no fun at all.

Luckely, there is a way to make your properties private while not losing the ability to do inheritance, or pay a costly runtime fee. Use Inside Out Object. Reverse the traditional roles of objects and properties. Let the properties be hashes, and the objects the keys:

    package My::Package {
        my %furble;
        my %oogle;
   
        sub oogle {
            my $self = shift;
            $oogle  {$self} = shift;
            $furble {$self} ++;
        }
    }
[download]

And how your inherited classes are implemented no longer matters. You'll never interfere with their properties, regardless what kind of conventions they use.

Abigail

Root of all evil -- wow! I don't think I've ever done anything that can be described as that. :-)

The poster seemed to be at a level where discussing this sort of reverse composition would be even more confusing. If I'm doing any sort of subclassing I generally use straightforward composition/delegation stored in a key derived from my class. But I entirely agree that these sorts of ugly hacks are necessary illustrates a fundamental flaw.

Chris
M-x auto-bs-mode