On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> So we need a mechanism that is externally (i.e. from a class interface
> point-of-view) a subroutine, but internally has the features of a method (i.e.
> has an invocant). Since it's externally sub-like but internally method-like,
> we call this useful construct a submethod.
Hmm, thanks.
For most of that, doesn't a private method suffice?
When it doesn't, I feel uneasy about:
class Foo {
submethod bar() { ... }
}
my $foo = Foo.new;
$foo.bar;
If that's externally sub-like, why does it look so much like a method?
Another thing that scares me with the "utility sub" point of view follows:
class Foo {
method process_data($data) {
$.help_process_data($data);
}
submethod help_process_data($data) {
$data+1;
}
}
Foo.new.process_data(0); # 1
class Bar is Foo { }
Bar.new.process_data(0); # dies[1]
What??? I didn't change anything yet! Why does it die? (This is the
first principle in the journal entry you quoted)
Let's presume that I want to extend Foo by adding a method completely
unrelated to process_data, and I would like its behavior to stay the
same for process_data. How would I do that?
Luke
[1] Well, it wouldn't, since for Liskov sanity we require that a
method of the same name already exists. Let's say that Foo's parent
class implemented "submethod help_process_data($data) { die }".
