4 ms·

> You would be able to call free-standing functions with a `this` argument left of the double colon, i.e. `thisArgument::freeStandingFunction()` If you're goin

> You would be able to call free-standing functions with a `this` argument left of the double colon, i.e. `thisArgument::freeStandingFunction()` If you're going to do that, you might as well do it the right way and make it `verb::theThing` instead. Alternatively, `with` is an existing reserved word that already kind of deals in this realm, as language semantics go. So... finishWork().then(placeOrder with deliveryService)

spion 9y ago
That would muddy the water even further, since `with` normally brings object members into scope. This is specifically about calling a non-member that is already in scope, as if it were a member. Its exactly the same as `freeStandingFunction.call(thisArgument)` It should be a primitive operator, not just a method on functions, because that allows you to explain x.method() without the explanation being self-referential i.e. fn.call(thisArgument) is a method call itself.
- carussell 9y ago
  > This is specifically about calling a non-member that is already in scope, as if it were a member. I understand what you wrote. `with` is reserved, but disused, however. And it wouldn't be the first reserved word that has different behavior based on the actual construct it appears in. Loops and switch statements both use `break`, for example. The language does this because the semantics are similar enough, and there's no point in polluting the list of reserved words when pulling double-duty with the one would do.
  - spion 9y ago
    In the case of 'break', it breaks out of the block of the current construct (loop, switch). with brings an object in scope, or calls something already in scope with the object as a this argument - the semantics will be exactly opposite in this case. Then it breaks chaining syntax (one nice thing we get), since everything will have to nest again: x::fn()::otherFn() vs (otherFn() with (fn() with x)) It brings more problems with ASI: fn() with (x); // is this fn() with (x), or fn(); with (x); do nothing

spion 9y ago

That would muddy the water even further, since `with` normally brings object members into scope. This is specifically about calling a non-member that is already in scope, as if it were a member. Its exactly the same as `freeStandingFunction.call(thisArgument)` It should be a primitive operator, not just a method on functions, because that allows you to explain x.method() without the explanation being self-referential i.e. fn.call(thisArgument) is a method call itself.

carussell 9y ago
> This is specifically about calling a non-member that is already in scope, as if it were a member. I understand what you wrote. `with` is reserved, but disused, however. And it wouldn't be the first reserved word that has different behavior based on the actual construct it appears in. Loops and switch statements both use `break`, for example. The language does this because the semantics are similar enough, and there's no point in polluting the list of reserved words when pulling double-duty with the one would do.
- spion 9y ago
  In the case of 'break', it breaks out of the block of the current construct (loop, switch). with brings an object in scope, or calls something already in scope with the object as a this argument - the semantics will be exactly opposite in this case. Then it breaks chaining syntax (one nice thing we get), since everything will have to nest again: x::fn()::otherFn() vs (otherFn() with (fn() with x)) It brings more problems with ASI: fn() with (x); // is this fn() with (x), or fn(); with (x); do nothing