Ambigousness

[adrianhelvik]

class MyClass { foo() { return 1 } }

function foo() { return 2 }

console.log(MyClass::foo()) // = ?

In my mind, the only reasonable thing here is that it is 1. I think binding to other functions on the scope is a minor use case and highly confusing.

I really like that A::B === A.bind(B) though. That's some nice syntactic sugar. In my opinion, the edge cases can be a bit more verbose and foo.bind(MyClass) is a nice and explicit way to do this.

My 5¢

[saschanaz]

I think MyClass::foo() is 2 and MyClass::(MyClass.prototype.foo)() is 1.

[InvictusMB]

@adrianhelvik Does this go in line with what you are stating here?

[ssube]

AFAIK, nothing in this proposal has suggested a change to scope resolution, so the log line only has one foo to reference (the other is MyClass.prototype.foo, as @SaschaNaz points out) and will return 2. Anything else would introduce a completely different set of rules for implicitly resolving prototype variables, which reminds me a lot of DOM elements being put in global scope by ID.

[bathos]

Is it possible that the confusion we’re seeing about this could be seeded by the usage style presented in examples, which follows the same pattern as the access operator? That is, would people still be mistaking this proposal for having to do with property access if the examples showed foo :: bar() instead of foo::bar()?

[adrianhelvik]

I made an error in my original post. I meant to say something along the lines of: let myClass = new MyClass, myClass::foo().

I also misread the proposal. ::console.log does what I thought console::log (and let log = console.log; console::log) would do. My mistake. I was on my way to work and saw what seemed like a massive blunder.