On Sat, 2005-10-29 at 17:30 -0400, Stevan Little wrote:
> 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.
Hmm. I think I much prefer;
method you_must_implement { ... }
or a trait, perhaps
method you_must_implement is required;
I think that methods disappearing out of scope in subclasses is just
Nasty And Wrong™, for the exact reason Luke outlined. Side-effects like
that are just asking for trouble IMHO.
> 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.
Good point, which is why the "is required" as above would be better.
It seems to me that there's an awful lot of specification going into
these varied types of methods.
Method Type Purpose Dispatch Visibility
---------------|------------------|---------------|------------
$.method() | external API | MMD | all
$.submethod() | refactoring | package | single
$:private() | internal API | package | single
I must admit I also fail to see the difference between submethods and
private methods. And what do I use for methods that I don't want to
make visible to "the world"?
Perhaps a more useful definition might be that submethods are only
available on $?SELF (and are still subject to normal dispatch).
Sam.
