Method, procedure, function. It's all the same thing. The thing that differes is how you call them. I'd say that

sub Foo::new {
  bless {}, $_[0];
}
[download]

is still a method even if you call it with Foo::new($class).

I can say black is white and white is black all day, but I'm still going to get run over at the next zebra crossing because it's not true. Method calls are invoked using $instance->method_name(). That form searches the @ISA tree. Foo::new() is calling a fully specified subroutine. No amount of wishful thinking will ever make that into a method call. Perl is rather flexible in that it will allow you to call most subroutines either way.

And strictly speaking (in a computer sciencey manner), there is a specific difference between a procedure and a function. Compare and contrast foldoc's definitions for function and procedure

I can say black is white and white is black all day

Or you can ask the author whether it's black or white -- that'll save you from getting run over.

Method calls are invoked using $instance->method_name().

Agreed.

Foo::new() is calling a fully specified subroutine.

Agreed.

No amount of wishful thinking will ever make that into a method call.

When did I claim that? My point was that it's the author that decides whether a subroutine should be a method or not. When I say method I speak of a subroutine that deals with classes/objects and/or is intended to be inherited/overriden, roughly. I believe that's the common interpretation.

Perl is rather flexible in that it will allow you to call most subroutines either way.

Exactly. The way we choose to call our subroutine doesn't change what the subroutine is. But if we want to call a private method, we can just as well call it directly -- and we should call it directly. See this node.

And strictly speaking (in a computer sciencey manner), there is a specific difference between a procedure and a function

I'm familiar with that from Pascal... But Perl makes no difference. In Perl there's no technical difference between methods, functions, and procedures; they're all subroutines. We are discussing Perl's object model, are we not?

Your phrasing made it seem as if you were claiming it was a method call. Upon rereading a couple more times, I see what you were implying.

And I was going to respond further, but I'm getting the distinct impression that IHBT. *plonk*

Interesting. I always implement all methods in module as methods. Private or not.

Consider Dave05s example, he has two method _write and _read, now we agree these methods are private as indicated by the underbar.

However where I disagree with you is what this type of privacy means. To me this means that I shouldnt call this method directly (even though I can, method or function) probably because theres no error checking of parameters or some such equivelent reason. However this does not mean that I should not re-implement these methods as necessary in a sub class. In fact these are precisely the two methods that are the most obvious way to alter the behaviour of his class. If I am forbidden from reimplementing these methods I would be forced to reimplement new(),DESTROY() and add new _write() and _read() methods, effectively rewriting half of his class. But if I can change _write() and _read() directly then I dont have to change the published interface at all. new() would simply call the new _read and likewise with DESTROY.

Now I know there are different schools of thought as to how public and private methods should work, but I know from my experience in Perl that the modules that are the easiest to subclass (excluding those which are _intended_ to be subclassed) are those that have _all_ of their subroutines as methods, leaving the least overriding needing to be done.

Peace,

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

Consider this:

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]

The author of Foo::Bar probably didn't know about Foo's &_init, and shouldn't have needed to either. Private methods are private methods. If you want your method to be overridable you shouldn't use a leading underscore and you should document it. Using method invocation on private methods isn't a problem for the module author, it's a problem for those that try to inherit it. If I use a leading underscore on a method in my module I expect that no one else runs it -- that counts for both deriving and derived classes. I also expect no one to override it. If I wanted that I wouldn't use a leading underscore.

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.