That’s not to say other people may or may not do it.

Maybe Perl 5->6 code translator most probably need to automatically convert some “sub”‘s to “method”, but I tend to think that Perl 5 coders should get used to write “method”.

After today’s p6m meeting, pmichaud explained in a better fashion how the sub/method thing works and it’s clearer to me. Having said that, you could always call a sub via it’s namespace, which would be IO::open() in this case.

I fully intend on following this up tomorrow (it’s rather late).

That’s a fair complaint, but it also highlights the original problem with perl 5′s reusing of subs as methods: you can’t tell that a sub is a sub and not a method.

Maybe the compiler could check for the use of an invocant in a sub in a class and issue a warning; that would help perl 5 users migrate.

That’s clearly crazy.

class Foo {
method open (…) { … }
method bar { open(…); }
}

If the invocant is to be assumed, then the above would call Foo’s open. But then how do I call perl’s open?

I would guess the answer to be related to your comment about “placing the object model above all else”. One of Perl’s defining characteristics is to *NOT* slavish follow dogmatic principles because what’s important are the _programmer’s_ opinions about how problems should be solved, rather than the language designer’s. So, while the object model is important, it’s not important enough to be the lens through which all problems are viewed.

chromatic:

I have a hard time believing that this would be too ambiguous in perl5. I don’t have the extensive perl5 CPAN publishing experience you do, though I have been doing my $DAYJOB in C/C++ mostly.

I agree that different things should look different. My argument was that sub, method, and submethod wen’t different enough. That is why I recommended a method modifier, similar to how C/C++/Java does it.

Lastly, my comment is based solely as a response to jnth’s comment about the preference of method dispatch over a little bit of OO clunkiness.

Moritz:

I actually like Perl6; I’m not griping or wining but hopefully trying to improve things for everyone. And yes, I fully intend on extending the STD grammar when macros are available.

fREW:

The point of the second example was to illustrate how annoying it was to constantly have to specify the invocant. After years of not doing that, it just seems logical that it would be implied within the class.

class A {
method foo {
say “nope”
};
method bar {
self.foo()
}
}

> The “many paradigms” argument is wrong because the
> language should do one thing and do it well.”

Sorry, Perl 6 is not the right language for you if that’s your opinion on language design. Perl always was a multi paradigm language, and will always be.

(If you want a really nice object system (without meta object programming, though) Eiffel would be a good choice.)

That said, I think that it’s very perlish to add new keywords and/or syntax for important features, so having a separate ‘method’ keyword is actually a sign that we take OO very seriously.