submethods' odd behaviour

[tobyink]

Some or perhaps all of these might be wrong.

$ perl -Ilib -Mmop -E'class Foo { submethod private { 42 }; method public { $self->private } } class Bar extends Foo { } say Bar->new->public'
Could not find private in Bar=SCALAR(0x982ce68) at lib/mop/internals/mro.pm line 141

$ perl -Ilib -Mmop -E'class Foo { submethod private { 42 }; method public { $self->private } } class Bar extends Foo { submethod private { 666 } } say Bar->new->public'
666

$ perl -Ilib -Mmop -E'class Foo { submethod private { 42 }; method public { $self->private } } class Bar extends Foo { method private { 666 } } say Bar->new->public'
666

[doy]

$ perl6 -e 'class Foo { submethod private { 42 }; method public { self.private } }; class Bar is Foo { }; say Bar.new.public'                     
No such method 'private' for invocant of type 'Bar'
  in method public at -e:1
  in block  at -e:1

$ perl6 -e 'class Foo { submethod private { 42 }; method public { self.private } }; class Bar is Foo { submethod private { 666 } }; say Bar.new.public' 
666

$ perl6 -e 'class Foo { submethod private { 42 }; method public { self.private } }; class Bar is Foo { method private { 666 } }; say Bar.new.public' 
666

So no, I think all of these behaviors are correct.

[doy]

In particular, submethods were never intended to be like private methods. They are intended to support things like BUILD, where every method in an inheritance hierarchy is called (so inheriting individual implementations of BUILD doesn't make sense), or for things like optimized constructors (for instance, we emulate this in Moose by generating a constructor that starts with my $class = shift; return $class->Moose::Object::new(@_) if $class ne __PACKAGE__;, which is effectively what submethod dispatch inherently does).

We should have some tests for this behavior, though.

[stevan]

Hmm, yeah, I think doy is right, at least as far as submethods are concerned. Lets keep this open so that we remember to write tests.

[stevan]

Actually, submethods are basically (kinda sorta mostly) lexical subroutines and should (perhaps) be implemented as such. See http://rjbs.manxome.org/rubric/entry/2016 for more info, specifically this bit:

If you make that subroutine lexical, you can't override it in the subclass. In fact, if it's lexical, it won't participate in method dispatch at all, which means you're probably breaking your main class, too! After all, method dispatch starts in the package on which a method was invoked, then works its way up the packages in @inc. Well, package means package variables, and that excludes lexical subroutines.

[doy]

No, they aren't - the whole point is that they are callable from outside of the class, they just aren't inherited. new as a submethod wouldn't be possible if it was a lexical thing. Private methods and submethods are two separate concepts.

[stevan]

Ah yes, you are right, I just saw the "does not participate in method dispatch" and my brain went off on a digression. Ignore my last comment.

On Sep 26, 2013, at 12:25 AM, Jesse Luehrs notifications@github.com wrote:

No, they aren't - the whole point is that they are callable from outside of the class, they just aren't inherited. new as a submethod wouldn't be possible if it was a lexical thing. Private methods and submethods are two separate concepts.

—
Reply to this email directly or view it on GitHub.