The colon marks the invocant of an indirect method call, at least if you're passing parameters. I realize you didn't pass parameters, but I recommend getting in the habit of always using the colon or never using indirect notation.

The purpose of requiring the colon is to disambiguate the language. Indirect object notation fails in difficult-to-debug places in Perl 5 and the goal is to avoid that in Perl 6.

The syntax and semantics of other languages don't really apply. This isn't C++ or Java. It's Perl 6. Unlike both languages, new is not a keyword in Perl 5 or Perl 6. It's a method call.

If Dog.new is a burden, consider using an in-place mutator:

I'll take this opportunity to complain again about the word "invocant". "Invocant" means "invoker" which means "caller". But it's being used to refer to the object, which is not the caller, it's the callee. It is the object, after all, not the subject.

In the cultures of certain other, more pure OO languages, the object of a method call is sometimes called the receiver, because calling a method is likened to sending a message. "Invocant" is just wrong, because the object does not call its own method.

I realize that in syntactic constructions like $obj->meth(), the object looks somewhat like it's taking an active role. But it's not.

I believe constructors are a special case that, if not promoted to being a keyword, should be close in precedence to keyword in terms of compile-time parsing. Regardless of the Perl5 doc misnomer of "indirect object," which we call more correctly "dative" for builtins like print() and tie(), the constructor in OOP is not the same as a dative and is more like this, to me: I am advocating for "what makes the most sense to a 'native' speaker/programmer" in the case of the constructor being NOT an indirect object but like the way both French and English says "nouveau riche" in the same way. This is what the French might call the English people (and later the Americans) during the Industrial Revolution. If you do what Wikipedia does and transliterate this, you would say "new rich" meaning new is an adjective qualifying the noun rich. Almost all of the time in other Romance languages besides English, the adjective goes after the noun ("mi camisa negro"). I believe a named constructor should behave like the way a *native* English speaker would translate this phrase, the more correct form as "newly rich" and not "new rich," maintaining that the qualifier goes before the noun. The point of the "indirect object syntax," which is a misnomer, in the case of constructors is a native speaker does not translate the phrase "nouveau riche" back into English. The phrase is well understood as-is in English. Thus, the constructor is not like any other method and, as someone has already pointed out, in this case we explicitly mean that the object does not call itself. You could have new, spawn, clone, gimmea, nextlike, &c. be explicit constructors and not subclassed or such. I am just saying the idea of this type of syntax is to raise our sophistication in the language, meaning we don't want people to "translate back" something for which we actually do want to be well understood in context syntactically, semantically, and overall grammatically.

Any word on why it isn't a keyword? I mean in perl6 you no longer define your own new. So is there a reason new isn't a key word that triggers the contructor? Like I said before, I wouldn't use inderict object notation anywhere else, but in the case of new it hardly feels like a method, and you are acting on a class not an object. I wonder if not making new a keyword is some attempt at leaving the language dynamic.

Update: Thanks for clarification on all points to both chromatic and TimToady

___________
Eric Hodges

It's not really quite accurate to say that you no longer define your own new. It's merely the case that you get a default new for free. However, that default constructor only handles named parameters. If you want a constructor that uses positional parameters, you have to define your own, and there's no reason you can't call it call it new if you like, presuming it's something that multimethod dispatch can sort out from the default Object.new().

By the way, I disagree slightly with chromatic on this point. I think new Foo without colon is just fine, since we've gone to some pains to make sure that 1) it works as MMD and that 2) neither the method name nor the class name are taken as barewords. You could just as easily write new(Foo) and it will still work via MMD. But there's nothing wrong with the colon, and different people value different kinds of consistency.

It's a class method you can override if you must. You probably ought to override BUILD() or BUILDALL() instead, but it's there if you need it.