(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)

On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message.  I'm assuming it should just be ".")
> No. There's now also a unary ./ operator in Perl 6.
> Unary . calls a specified method on the current topic.
> Unary ./ calls a specified method on the current invocant.
> The point being that methods no longer topicalize their invocant. So you need
> to use ./ instead of . to call methods on an implicit invocant.

Someone pointed me to the giant p6l thread on this issue (which I now recall
seeing in my email client months ago but totally ignored at the time for
some reason).  As you might guess from my initial identification of this
syntax as some sort of text mangling bug in Gmail, I'm not a fan.  I get the
shell connection but that / just screams "file path" to me, not "object" or
"invocant."  Forgive me for coming in late, but here's hoping it's better
than never :)

I was all ready to suggest .:method, but then I was reminded of that
syntax's other purpose.  I'm not, however,  buying Damian's argument here:

On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said:
> This missing design rationale here is that the colon acts as part of the unary
> operator:
>      ./    unary public-method-call-on-invocant
>      .:    unary private-method-call-on-invocant

It strikes me as more of a "rationalization" than a "rationale"--picking out
patterns after the fact, because that's what our brains like to do.  So if
you're willing to give up this nugget of comforting symmetry, I propose

       .:     unary public-method-call-on-invocant
       .::    unary private-method-call-on-invocant

Okay, now maybe it looks like a package separator instead of a file path,
but at least that's in the OO ballpark.  I also admit to not fully
understanding any possible parse/lex implications.  But assuming it's
possible, I like it a lot better than "./"

All three keys are in a tight little cluster, so the odds of typo-ing a
public method call to a private method call seem about equally likely in
both cases, even allowing for the different uses of shift.  One is not much
more difficult to type than the other either.

The .:: also looks "deeper" to me, suggesting "private."  See what I mean
about picking out patterns after the fact? ;)  But the truth is that /
really does look file-path-y to me, and just plain old ugly.  I think at
least two other people had similar reactions (Martin Kuehl and Carl Franks).
Maybe .:: has even more detractors, I dunno.  All I know is that I dislike
./ and I'm trying to come up with an alternative.  What say you all?  Too
many dots in .::?  Surely ./ isn't as good as it gets...

Anyway, sorry for the thread necromancy, but I let -> drift away with barely
a whimper and so I think latent guilt may be driving me to fight for this
one at least a little bit... :)


Reply via email to