Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public and private class fields

developers.google.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Public and private class fields

#81

Post by danShumway »

BillinghamJ wrote: post #74
danShumway wrote: post #67

Am I the only person who's really stinking annoyed that Chromium is just randomly shipping features that haven't gone through the W3C? Didn't we learn anything from the early days of CSS and browser flags? Didn't we learn anything from flexbox? Don't call it a proposal if you already have plans to ship it. Private fields haven't been accepted as a standard yet. They should not be shipped except behind a browser flag.

First, the definition of JS has nothing to do with W3C. (Also for HTML, nobody really cares what W3C thinks anyway) Second, the rules of how JS is standardised is that changes are actually not allowed to go into the final spec until at least two major players implement support. So this is _exactly_ how it's meant to be done. A substantial amount of discussion and consideration has already happened prior to this point…

Implementing support is not the same thing as turning a feature on by default.

The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways.

> as well as implementations into trans pourers (eg Babel)

Which is meaningless. Babel is not a part of the standards process, they're free to ship anything they want. Encouraged, in fact, because that provides more in-the-wild usage data.

Re: Public and private class fields

#82

Post by Roboprog »

BillinghamJ wrote: post #78
fsnarskiy wrote: post #63

Why? I feel like the person who proposed this is relatively young and newer to coding. The reason why i say this is the functionality he is proposing can already be done using one of the myriad of JavaScript design patterns - https://addyosmani.com/resources/essentialjsdesignpatterns/b... It can already be done in a clean and easy way with a an anonymous self executing function - (function(){//EVERYTHING HERE IS PRIV…

Making classes (or equivalent) in the way you propose - ie "make use of closures for private instance fields" - does not work well. It requires allocating a new copy of each of the class's methods every time the class is instantisted, working around the prototype system. If we're arguing about crappy misuse/abuse of JS and "doing it wrong", surely this is far worse?

I would be interesting to see exactly how much stuff is copied by the various implementations in such cases.

There are obviously some stack or other data frames that have to be captured somehow, but the code itself should in principle be something the VM makes a single copy of with references to in each object using it as a property. (Internally within a Function type reference, separate trackers for the instructions vs the bound data)

Re: Public and private class fields

#84

Post by Roboprog »

shiado wrote: post #50

How does this work with JSON.stringify? Could I convert an object to a string and then scan the string to get the value of the private fields? (I am not great at the details of JS correct me here)

That’s actually a pretty good question. It’s probably in the spec, which is probably long :-)

Re: Public and private class fields

#86

Post by BillinghamJ »

randomsearch wrote: post #59

To reiterate what others said, choosing an unusual syntax that is non-obvious motivated by a synthetic example to solve a problem already solved by many other languages in better ways almost raises the suspicion that we’re deliberately trying to make JS even worse... to kill it? Or is this just indicative of the process that got us to this mess in the first place? A more reasonable policy for JS would be to (a) conta…

You know a lot of people actually like JS right?

The second paragraph you wrote seems to indicate that you believe people only use JS because they're forced to - since browsers don't support anything else.

That's not the case. People choose to use JS in all sorts of places where they could make use of many other options.

Development of the JS spec is complicated somewhat by the strict rules of web compatibility. But imo the benefits of that compatibility guarantee far outweigh the downsides. Having slightly ugly/unusual syntax is not a major issue.

Re: Public and private class fields

#87

Post by james-mcelwain »

jamestimmins wrote: post #76
denisw wrote: post #21

Earlier quoted context omitted.

One important thing to note here is that this goes much further than `private` in TypeScript. The latter is purely a compile-time illusion. If you write `private x`, your objects' x property is still publically accessible and modifiable as far as the JS runtime is concerned. any other. It‘s just the TypeScript compiler that gives you an error if you access x, and only if it happens to have the type information it nee…

Does this mean that with TypeScript someone could still see private values if they used their developer console on the browser, but with this approach that would be impossible?

Access modifiers in TS are compile time only checks.

This change is not about visibility in dev tools. I'd imagine you'll still be able to see and mutate private fields in dev console, just like you can in a Java debugger, etc.

This change is for libraries, so that if someone consumes a TS library, for example, they can't monkey patch or otherwise touch private fields at runtime.

Re: Public and private class fields

#88

Post by BillinghamJ »

danShumway wrote: post #81
BillinghamJ wrote: post #74

Earlier quoted context omitted.

First, the definition of JS has nothing to do with W3C. (Also for HTML, nobody really cares what W3C thinks anyway) Second, the rules of how JS is standardised is that changes are actually not allowed to go into the final spec until at least two major players implement support. So this is _exactly_ how it's meant to be done. A substantial amount of discussion and consideration has already happened prior to this point…

Implementing support is not the same thing as turning a feature on by default. The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways. > as well as implemen…

Fixed the autocorrect error.

It is super meaningful - it helps identify potential issues in real world use-cases and it creates effectively a "market" of people already using the feature who want to be able to use it without transpiling. It's also pretty rare that the implementation changes meaningfully after implementation into Babel from around stage 2.

Re: Public and private class fields

#89

Post by strainer »

rictic wrote: post #56
mkozlows wrote: post #5

This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.

That means that for every incrementer you create, you've also got to allocate two additional functions: value and increment. They have to be distinct objects, because `incrementer().value === incrementer().value` must yield false. Debugging is also harder. When you're debugging and you find an incrementer somewhere else in your program (maybe somewhere unexpected), how do you know what kind of thing you have? All you…

Comparing these function references: `a_inc_instance.value === b_inc_instance.value` is true in javascript when the function `value` is a class method.

In the closure/factory created version it is false - each function `value` is a different instance with a different reference. That will involve unnecessary duplication in the interpreter, but also allows for the function to be optimised for its state (monomorphic etc) which can be significant when more than a simple example `x++` operation is involved.

So the class version does entail less memory usage, but the closure permits more JIT optimisation.

> If it were a class instance you could ask instance.constructor.name to find out that it's an Incrementer, so you can grep for `class Incrementer`.

Im not sure how much extra help that kind of thing is, we might instead grep for `symbol\s*=` to find where a symbol was assigned whether it had a .constructor.name property or not. I can see it is a general advantage of having more types, to have summary information besides the names.

Re: Public and private class fields

#90

Post by BillinghamJ »

Roboprog wrote: post #82
BillinghamJ wrote: post #78

Earlier quoted context omitted.

Making classes (or equivalent) in the way you propose - ie "make use of closures for private instance fields" - does not work well. It requires allocating a new copy of each of the class's methods every time the class is instantisted, working around the prototype system. If we're arguing about crappy misuse/abuse of JS and "doing it wrong", surely this is far worse?

I would be interesting to see exactly how much stuff is copied by the various implementations in such cases. There are obviously some stack or other data frames that have to be captured somehow, but the code itself should in principle be something the VM makes a single copy of with references to in each object using it as a property. (Internally within a Function type reference, separate trackers for the instructions…

Normally it could be effectively optimised away and just treated as an extra argument.

But it's also required by the spec that `foo().method !== foo().method` when returning new functions from a closure in `foo`, so the function has to be wrapped and a new structure allocated each time to differentiate.

Post reply on HN