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;

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) {
        submethod help_process_data($data) {

    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?


[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 }".

Reply via email to