Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

submethods' odd behaviour #76

Closed
tobyink opened this issue Sep 17, 2013 · 6 comments
Closed

submethods' odd behaviour #76

tobyink opened this issue Sep 17, 2013 · 6 comments

Comments

@tobyink
Copy link
Contributor

tobyink commented Sep 17, 2013

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
Copy link
Collaborator

doy commented Sep 17, 2013

$ 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
Copy link
Collaborator

doy commented Sep 17, 2013

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
Copy link
Owner

stevan commented Sep 17, 2013

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
Copy link
Owner

stevan commented Sep 26, 2013

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
Copy link
Collaborator

doy commented Sep 26, 2013

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
Copy link
Owner

stevan commented Sep 26, 2013

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.

@doy doy closed this as completed in b337e9a Sep 27, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants