use strict;

package Foo;

sub new {
    my $class = shift;
    my $self = bless {}, $class;
    $self->_init;
    return $self;
}

sub _init {
    my $self = shift;
    $self->{important_flag} = 1;
}

package Foo::Bar;
use base 'Foo';

sub new {
    my $class = shift;
    my $self = $class->SUPER::new(@_);
    $self->_init('har har har');
    return $self;
}

sub _init {
    my $self = shift;
    $self->{ext_prop} = $_[0];
}

package main;
use Data::Dumper;

my $foo = Foo->new;
my $bar = Foo::Bar->new;
print Dumper([$foo, $bar]);

__END__

$VAR1 = [
          bless( {
                   'important_flag' => 1
                 }, 'Foo' ),
          bless( {
                   'ext_prop' => 'har har har'
                 }, 'Foo::Bar' )
        ];
[download]

Hmm, yes. There was an interesting conversation on the CB here today about this matter. Ive got to edit it before I post it, but if you check my homenode youll see it (or a link if I post it elsewhere).

The rub however was the issue of method namespaces and precisely the issue to which you refer, the meaning of the underbar.

To me (and it seemed quite a few other people) the underbar says to the consumer of the class, "DONT USE ME", but to the developer/extender of the module it says "THERE ARE SPECIAL RULES FOR USING THIS METHOD". Special mention was made of wrappers for recursive subs and other utility type scenarios.

Now others see it as you appear to, the cut and dried, "PRIVATE, IMPLEMENTATION MIGHT CHANGE". Personally I think that this interpretation of the convention while perhaps suitable in other languages is not so suitable in Perl. It fails to account for a need for the special rules type functions and marking them as distinct.

I might be weird, but if a sub is going to change interface then it should be documented accordingly. Simply expecting me or any other programmer to interpret "private" in the same way that you do is unreasonable in a language like perl where there is no concept of privacy (er caveats of course :-)

Anyway, I really wish you would unmask yourself, itd be easier to carry on this conversation...

I suppose you have your reasons however. :-)

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

It [Perl] fails to account for a need for the special rules type functions and marking them as distinct.

From perltoot:
Perl doesn't impose restrictions on who gets to use which methods. The public-versus-private distinction is by convention, not syntax. /.../ Occasionally you'll see method names beginning or ending with an underscore or two. This marking is a convention indicating that the methods are private to that class alone and sometimes to its closest acquaintances, its immediate subclasses. But this distinction is not enforced by Perl itself. It's up to the programmer to behave.

It's at least mentioned in the documentation. I guess some people skip perltoot though and dig right into perlobj. Perhaps this should be mentioned in perlobj too?

You again:
I might be weird, but if a sub is going to change interface then it should be documented accordingly.

But underscored methods are usually not documented and thusly isn't in the interface. They're just internal implementation.

Simply expecting me or any other programmer to interpret "private" in the same way that you do is unreasonable in a language like perl

I think it's fair to expect that undocumented methods aren't public.

...where there is no concept of privacy (er caveats of course :-)

By using a function call instead of a method call he does enforce some privacy. He disables you from overriding the routine.

Anyway, I really wish you would unmask yourself, itd be easier to carry on this conversation...

I doubt you'd recognize me.

I suppose you have your reasons however. :-)

Yes, I haven't registered. :)