...and that's the point. A leading underscore indicates a private method
Er, no.
The point is that its not a method. Its not a private method and its not a public method because it is not a method at all.
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look. | [reply] |
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];
}
is still a method even if I call it with Foo::new($class).
Or what about this:
my $bar = $foo->can('bar');
$bar->($foo); # Is there any difference between this &bar
$foo->$bar; # and this &bar?
There are times when you wish to specify which class's method to use. Here you can call your method as an ordinary subroutine call, being sure to pass the requisite first argument explicitly /.../ Unlike method calls, function calls don't consider inheritance. (perlobj)
And this is exactly what we want... or at least what Dave05 intended. He even wrote that the subs are private. &_write takes an object as the first argument, so it's effectively the same thing as a method, hence you could say "private method", and private methods shouldn't be invoked as methods. Invoking private methods as methods will lead to Bad Things.
| [reply] [d/l] [select] |
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];
}
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
| [reply] [d/l] [select] |
Invoking private methods as methods will lead to Bad Things.
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.
| [reply] |