The example method in the "Inheritance" section contains a line my $name = self->next::method. This leaves unclear whether it means my $name = self->next::method() (because the name method takes no parameters) or whether it means my $name = self->next::method(@_), i.e. the current parameter list is passed unchanged.
If it is the first alternative, just adding the parens will make that clear.
If it is the second, then this impedes an use case for inheritance where the derived class is actually a special case of its parent class. For example, a cube is a cuboid, or in Corinna speek, class Cube :isa(Cuboid). However, a cube only takes one parameter on construction and also on methods. A resize method for a cuboid takes three parameters, the equivalent method for a cube takes only one.
The example below shows how I'd like it to work (it also shows some known deficiencies which we currently have with inheritance: I have to define defaults, and to expose writers for all slots which might be special-cased by subclasses).
It meant my $name = $self->next::method(). It wasn't intended to automagically pass through parameter lists. I've added the parentheses to the examples.
The example method in the "Inheritance" section contains a line
my $name = self->next::method
. This leaves unclear whether it meansmy $name = self->next::method()
(because thename
method takes no parameters) or whether it meansmy $name = self->next::method(@_)
, i.e. the current parameter list is passed unchanged.If it is the first alternative, just adding the parens will make that clear.
If it is the second, then this impedes an use case for inheritance where the derived class is actually a special case of its parent class. For example, a cube is a cuboid, or in Corinna speek,
class Cube :isa(Cuboid)
. However, a cube only takes one parameter on construction and also on methods. Aresize
method for a cuboid takes three parameters, the equivalent method for a cube takes only one.The example below shows how I'd like it to work (it also shows some known deficiencies which we currently have with inheritance: I have to define defaults, and to expose writers for all slots which might be special-cased by subclasses).