20

In ESnext, private properties are marked with `#`.

Who thought that was a good idea? No really, who thought that was a good idea?

Why not just -- I don't know -- introduce keywords like ... let me think ... public, protected and private!?

Why this:

class MyClass {
a = 1; // .a is public
#b = 2; // .#b is private
static #c = 3;// .#c is private and static

incB() {
this.#b++;
}
}

If this becomes part of the language, no JavaScript developer may joke about php usage of `$` anymore.

Comments
  • 23
    Why are you commenting out your private variables?
  • 8
    @C0D4 So nobody can change them. ;)
  • 7
    See here's the thing.. I can make non-stop jokes at the expense of JS and I can never get tired nor bored of doing just that.

    Now, before you jump to conclusions, I have done some JS work with Node.

    But, even though I have an infinite amount of ammo against this horrible language and the cancerous trend it is setting for software development in general... I want to see this crap included just so I can even more non-stop fun of it.
  • 1
    Here's the link to the proposal: https://github.com/tc39/...
  • 0
    Looks strange, but semantic naming, to express visibility and other options, is not that uncommon.
  • 6
    @k0pernikus one more thing that doesn't sit right with me here: why is JS trying to be more OOP?

    We hear functional devs complain about OOP and how shit it is and yet here is JS trying to be more OOP... and failing miserably at it like every other time it tried to so something.

    Shouldn't the focus now be on fixing the actual piles of shit like the stupid === or all the other gotcha's the language has?

    Best one yet is that no JS dev can for a fact tell you the meaning of 'this' by quickly looking at a snippet of code.
  • 11
    🤦‍♂️haha but of all characters... a #?

    I've seen "private", I've see underscores l, hell I've seen

    var private_xyz = this.arg;

    Inside functions, but a #?
    A symbol universally known across a lot of languages... as a comment....

    I don't understand this world some days.
  • 4
    @MrCSharp My guess is that JavaScript feels intimidated by TypeScript and wants to make it obsolete. TypeScript strongly favors an OOP approach.

    Furthermore, I would call neither plain JavaScript or TypeScript functional. You can do "basic" functional programming but it's best to use libraries for that. E.g. currying in plain JS is a pain in the ass.
  • 4
    There's a document explaining the reason behind choosing the # character over others, including the underscore. It says using the underscore could break existing code, so they discarded it.

    I mean, yeah, technically you could break the code of some poor bastard that named his variables with a leading underscore without considering them as private, but come on, everybody and their grandmas know that leading underscores mean private variable. Moreso in case of class properties, which are somewhat recent.

    I can't think of a legitimate case where some JavaScript code used leading underscores for variables not considered private and it wasn't developed by a moron.
  • 1
    Obviously the best thing is to copy everything straight from Java. This is not a joke
  • 1
    Looks ugly to me too but apparently there's a technical limitation on the language. Shocking.
  • 3
    @AlgoRythm I'm not sure I understand their reasoning. So instead of having a flag (public/private) which they query which is apparently slow, they rather want to check the name of the variable each time to determine if it's public or private?
  • 0
    I agree with @FrodoSwaggins.
  • 0
    @12bitfloat Guess so. Maybe the overhead of checking variable properties is more than that of taking the first character of the string.
  • 0
    @AlgoRythm I would hope it would be. I mean they will have to check visibility anyway. So what's their problem?
  • 1
    @Root and what did he say?
  • 4
    @MrCSharp JS crap like === can not be fixed without breaking backwards compatibility. And that will never happen. It's practically not fixable. No amount of new features and 'improvements' will fix the shitty foundation JS is based on. It's a dead end.

    JS is not bad because it is missing something. It is bad because it builds upon a pile of shit. A very accessible and easy to use pile of shit.
  • 2
    @Lensflare Luckily WASM is moving forward pretty quickly
  • 0
    @12bitfloat accidentally typed less instead of more.

    I do not know the intricacies of JS interpreters but according to those who do, it is more efficient with an ugly name.
  • 2
    @AlgoRythm I don't mean asm.js, I mean actual binary has-nothing-to-do-with-javascript webassembly
  • 3
    Backwards compatibility is the bane of JS. It's evolved a hell of a lot as a language, but it's always going to be constrained by its conception as a way of making animated monkeys dance on webpages in the 90's.

    A new language that avoids all the JS crap would be fantastic. Unfortunately though, no-one could ever agree on what that language should look like or how it should behave. Heck, I think you'd have devs split 50/50 on whether it should be typed, for instance.
  • 1
    @12bitfloat I think we've gotten lost thanks to devRant's non-hierarchical comment system. I'm gonna bail but I think we agree!
  • 3
    @AlgoRythm He hasn't yet, but I know what he would say. Web development, specifically frontend, is a cancer that only ever gets worse and makes him (and me) question their desire to stay in this field, and the sanity of the human race. He's not wrong. The future does indeed look bleak.
  • 1
    Up until this point I could bear JS, because ES6 is actually nice in my opinion and see it as an actual improvement for the language. But this bs reverses that. Just be like python then that you should not access variables prefixed with an underscore. If the implementation is going to be garbage why even bother with it?
  • 0
    @dUcKtYpEd Or poeple can use WASM with a Dart or Kotlin transpiler
  • 2
    Wait some people are really annoyed by the $ in PHP?
    I actually love it!
    Makes it super easy to differentiate between functions/methods/etc and variables!
    And if the parser can identify vars easily, you get some really useful functionalities like injecting vars into a string:

    @highlight
    <?php

    $test = 'World';
    echo "Hello $test"; // Outputs "Hello World"

    ?>
  • 0
  • 0
    @Skayo String interpolation also works in many languages without requiring a dollar sign for every variable
  • 1
    <@12bitfloat>
    That's just an example
  • 1
    @Skayo It's definitely more consistent, something a lot of languages could learn from
  • 1
    @Skayo Yes, I heard complains about that from JS-fanboys.

    I used to write a lot of php so I got used to it. Now, that I have written loads of TypeScript and Scala, it feels redundant and iffy. So I am not saying that the mandatory `$` is a good thing.

    At least it's used more consistent though as a variable identifier instead of a cryptic access modifier.

    Whenever I go back to php, I now tend to forget to write out the `$` as it feels redundant.

    That being said, my IDE phpstorm will let me write normal words and will fill in the `$` sign for me depending on the context due to auto completion.
  • 1
Add Comment