Re^2: $functions xor $methods

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

Comment on Re^2: $functions xor $methods Select or Download Code

Replies are listed 'Best First'.
Re^3: $functions xor $methods by Aristotle (Chancellor) on Oct 30, 2002 at 13:26 UTC
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]
(tye)Re2: $functions xor $methods by tye (Sage) on Oct 30, 2002 at 15:20 UTC
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]