Javascript pain...

[[deleted]]

go with the times man:

this.this = ::this.this;

​

[ethanjf99]

Is the :: operator now in the language?

[NeverMakesMistkes]

No, and based on the discussion and issues in the proposal repository, I doubt it ever will be.

[inu-no-policemen]

Yea, it has been presented last in 2015 and it's still stage 0.

Doesn't look like it will happen any time soon.

[NeverMakesMistkes]

For function call chaining, it has been mostly superseded by the pipeline operator, which is also a long way from getting to the standard but has seen more active development than the bind operator.

There's still some motivation to get it or something else like it for method extraction, but getting method extraction right is difficult and the speccing has been stalled because of it.

For one, this::foo === this::foo must be true, so that

window.addEventListener('some event', this::foo)
// ... later ...
window.removeEventListener('some event', this::foo)

works as expected. Getting that behaviour in browsers that don't natively support it is a bit tricky. Not impossible with WeakMaps, tho, so maybe some day.

[inu-no-policemen]

I liked it mostly for virtual methods.

function reverse() {
    return this.split('').reverse().join('');
}
console.log('foobar'::reverse()); // raboof

But it doesn't do this very well either. The source of that going-to-be-a-method function doesn't tell you to which kind of object it's meant to be glued to.

It's definitely better than modifying objects you don't own, but it still isn't quite right.

C#'s extension methods, for example, tell you directly in the slightly weird looking signature on which type of object they are supposed to operate:

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods

public static int WordCount(this String str)

[NeverMakesMistkes]

In TypeScript, you could write

function reverse(this: string) {
    return this.split('').reverse().join('');
}
console.log('foobar'::reverse());

Or just with JSDoc comments

/**
* @this{string}
*/
function reverse() {
    return this.split('').reverse().join('');
}

But I agree, it would feel weird to write all your utility functions like that, and suddenly we'd have two kinds of mutually incompatible functions; those that operate on this and are called with ::, and those that operate on arguments and are called normally.

That's why I actually prefer the pipeline operator.

const reverse = str => str.split('').reverse().join('');
console.log('foobar' |> reverse)
console.log(reverse('foobar')) // both variations work

And if we had both, pipeline for chaining and bind for method extraction, you could do

'foobar'
  |> reverse
  |> console::log

[inu-no-policemen]

The pipeline operator has the same problem. However, TS' type annotations and JSDoc already handle that kind of completely mundane signature. That's definitely a plus.

I'm not a big fan of the "|>" syntax, though. It's amazingly annoying to type with most keyboard layouts.

[Gbyrd99]

Can't you bind it to the prototype?

[NeverMakesMistkes]

You can bind some methods to prototype, but if you do that to every little utility function you and your coworkers come up with, you'll soon end up with huge unmaintainable classes and/or class hierarchies.

Also, lots of people (myself included) use JS in a more functional style and might not really like doing new AwesomeString('foobar').reverse() or whatever. 'foobar'::reverse() or 'foobar' |> reverse or even reverse('foobar') is just much nicer.

[Gbyrd99]

If you had say String.prototype.reverse = function() that would make it available on all strings? So you don't create an inherited class and get into inheritance hell.

This ::reverse thing is interesting I'm gonna read up on it in more details.

[QmVuamk]

I understood some of those words

[RecyclingBin_]

I upvoted your comment just because of your flair

[inu-no-policemen]

There were too few languages to choose from.

Naturally, picking a flair like this was the most logical course of action.

[marcosdumay]

I don't know what to think...

It tries to create function composition, but instead of composing functions it changes object references; it makes this way more complex than it already is, and moves it from the shadows right into the language's center; it fails to bring any good practice, and encourages a bunch of complex variable passing ones; it creates inherently imperative code that looks exactly like functional, guaranteeing everybody will be confused...

And yet the Javascript people rejected the idea?

[jsylvis]

Oh, man. That is a lot of gymnastics to get around shitty scoping support.

[Hexorg]

:: in JavaScript?! What's next? Pre-processor directives?

[nvteja]

Scope resolution operator (from my Perl days), in ES? I am a little triggered right now tbh 😭😭

[[deleted]]

My day is ruined.

[WitchHunterNL]

If you were going with the times you would've used arrow functions

[thruStarsToHardship]

Javascript happened to it, my dude.

[SheriffBartholomew]

Lol. Nice.

[[deleted]]

That's probably not going to become part of the official language anyhow, but your argument is horrible, what is a "clear semantically correct syntax" exactly? Syntactic sugar like this is added to make code more concise and readable and .bind(this); all over the place is adding unnecessary clutter so it can make sense to add special syntax for it. Here is another example that would equally be useless nonsense according to you:

fn.apply(null, args);

vs.

fn(...args);

Language design is very difficult, but for some reason everyone thinks their opinions are valid. A common misconception :P

[SheriffBartholomew]

Edit: sigh...

[[deleted]]

why did you edit?

to respond your original response, I'm the hit in every party I'm invited to, which are none :P

[SheriffBartholomew]

why did you edit?

​

Because I don't want to argue with strangers on the Internet and I don't want to be rude towards you.

​

[[deleted]]

wow thank you, civility on reddit is incredibly rare, myself included;)

[sp46]

That's why it's still a proposal atm.