Luke,
On Oct 29, 2005, at 3:42 PM, Luke Palmer wrote:
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)
This is true, but I think that it is easily rectified. A submethod is
said to have an implicit
next METHOD unless $?SELF.class =:= $?CLASS
I think we could add onto that and say that in addition to checking
the invocant's class, we could also check the calling context, and do
like we do with private methods, and allow things like this to Just
Work.
However, it could also be that the creator of Foo did not intend for
subclasses to be able to "Just Work", and that the whole idea of Foo
is to do a "Template Method" style pattern in which subclasses must
implement the &help_process_data submethod in order for things to
work. This is an entirely valid usage for a submethod, and in fact, I
think it is an excellent way for implementing the "Template Method"
pattern.
It is also possible that we could bring over the role idea of
"required methods" and have the same basic principle relate to
classes and submethods. If marked as such, a submethod is required to
be implemented by a subclass, or class composition fails. I think
that could be a useful feature which would allow very safe re-use
along those lines.
Anyway, just my 2 cents.
Stevan
