in reply to $functions xor $methods

I made this mistake with some OO modules of mine, even those I released to CPAN, I think. The "problem" (that we have to live with) is that method calls are slower than function calls (since Perl needs to look through the inheritance tree to find what method gets called). It's just something you have to do.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Replies are listed 'Best First'.
Re^2: $functions xor $methods
by kelan (Deacon) on Oct 30, 2002 at 13:13 UTC
    Couldn't you circumvent this "problem" by calling methods as functions inside the class definition? So instead of doing 
    sub foo {
  my ($self, $data) = @_;
  $self->{bar} = $self->method($data);
}

    [download]
    why not do this: 
    sub foo {
  my ($self, $data) = @_;
  $self->{bar} = method($self, $data);
}

    [download]
    Then the interface to the method will remain subclassable, but you don't have the performance hit of a method call. As long as this stays hidden inside the class, and you know the method you want to call is in the class and not a superclass, I don't see what the problem would be.

    kelan

    Perl6 Grammar Student

[reply]
[d/l]
[select]
      Unfortunately, that's not subclassable. The method-as-function calls in the super class will always call the super class functions, even when a subclass overrides them.

      Makeshifts last the longest.

[reply]

        That is a separate issue. If you are writing a module that you want to support subclassing of and you have a function that you want to allow to be overridden, then you should probably just make it a method.

        But it is perfectly reasonable to write a module that you want to support subclassing of but that uses utility functions that should not be overridden because they are tied to some current implementation detail that you might want to change later without breaking current subclasses.

        A separate issue is whether you want subclasses to be able to conveniently call this function. The previous solution accomplishes this but doesn't allow for overriding, which is probably the right solution for some cases.

        Perl is a bit strange for a language that supports OO in that it provides no features for separating the details of your module that 1) are implementation details that you want to keep completely to yourself so that you can create a new version that improves some things without breaking other people's code, 2) are suitable for use by a subclass, 3) are suitable to be overridden, 4) are to be used when the module is used.

        This, however, does not mean that every single detail of your module should be in (3).

                - tye
[reply]

In Section Meditations