Add explanatory note on method extraction with extended member expressions

[zenparsing]

Explain the behavior of something like:

(::a.b.c.d)

[ckknight]

Given that :: is lower-precedence than ., am I correct in assuming that the following expressions are equivalent?

::a.b.c

and

::(a.b).c

Rather than

(::a.b).c

Which would at least violate the principle of least surprise for me.

[zenparsing]

@ckknight That's right, and it makes sense if you think of :: in this case like any other unary prefix operator.

For example, these are equivalent:

typeof a.b.c;
typeof (a.b).c;

But they are not equivalent to:

(typeof a.b).c;

On the other hand, my feeling is that the prefix form of :: is just kinda weird in general and I'm not surprised that you find it surprising. : )

[RReverser]

What about

var f = obj::a.b.c;

Is it equivalent to

var f = a.bind(obj).b.c

rather than

var f = a.b.c.bind(obj)

?

[zenparsing]

@RReverser

Dot . always binds tighter than ::, so your example would be equivalent to

var f = (a.b.c).bind(obj);

Which is what esdown outputs. If you go to http://zenparsing.github.io/esdown/repl/ and type in:

.translate var f = obj::a.b.c

I'm wondering though, if having both the unary form and binary form is too confusing, and if one should win out, which would it be?

[RReverser]

I do see benefits from both forms, so wouldn't really drop any (and would even add the one from #5), it's just that they seem to have different rules which confuses a bit.

Also, it would be really helpful to use #4 and limit unary form only to MemberExpressions.

[dead-claudia]

Actually, it doesn't really surprise me that much. It appears that it acts more like this:

::a.b
a::a.b
a.b.bind(a)

::a.b.c
a.b::a.b.c
(a.b).c.bind(a.b)

::a.b.c.d
a.b.c::a.b.c.d
(a.b.c).d.bind(a.b.c)

That's exactly what I would expect to see with the unary form. And as for having two different forms for the same operator, I don't see the problem.

Now, I do agree that the right hand side for the unary form should be exclusively limited to MemberExpressions, since there exist absolutely no use case for anything else.