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

JavaScript TC39 implementing hashmark private class fields

github.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: JavaScript TC39 implementing hashmark private class fields

#71

Post by ubertaco »

erikpukinskis wrote: post #62
Andrex wrote: post #46

Earlier quoted context omitted.

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before. Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

ES2015 classes are not easier to learn for newbies, they're easier to learn for Rubyists and other people coming from OO languages. There's nothing hard about this: function Person(name) { this.name = name } Person.prototype.greet = function() { return "Hi, "+this.name } var me = new Person("Erik") console.log(me.greet()) The syntax hurts your brain if you're used to looking at something else, but the control flow is…

Which is easier, explaining to your hypothetical total beginner what "Person.prototype" is and going down the rabbit hole of prototype-inheritance, and explaining how Javascript functions (unlike just about every other language's functions) can have attributes on them and can act like fake constructors and what "this" means in your example (and then later what it means in a different case, since it means so many different things)...or simply saying "yeah, we can define a new category, or 'class', of things called Person by saying 'class Person { ....'"?

Re: JavaScript TC39 implementing hashmark private class fields

#72

Post by barleymash »

hajile wrote: post #63
cromwellian wrote: post #30

Earlier quoted context omitted.

Does this scale in a large code base? What's the effect on memory and performance of hiding most of your fields by closures?

Closures in JS are basically objects that have only one public property (called apply). Modern JITs are good at optimizing static objects (provided props are never added or deleted and the types never change). There is still (from what I remember) a small performance increase to normal objects, but it only becomes significant if you are creating hundreds or thousands of them. I'd say that in typical cases though that…

> Closures in JS are basically objects that have only one public property (called apply).

Never heard it explained this way. Can you elaborate a bit? I'm not sure I follow. Couldn't a closure have any of the same properties that other functions have? Call, apply, bind, length, etc, etc.

Re: JavaScript TC39 implementing hashmark private class fields

#73

Post by gulbanana »

pjmlp wrote: post #67
just_astounded wrote: post #58

Earlier quoted context omitted.

Until wasm has GC, we're not likely to see much in the way of compile-to-web outside of C, C++, or Rust.

There is already a .NET prototype. https://github.com/SteveSanderson/Blazor https://www.youtube.com/watch?v=MiLAE6HMr10 WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well. As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.

blazor is not .NET compiled to WASM. blazor uses a .NET runtime called DotNetAnywhere, which is written in C and compiled with emscripten. the actual .NET IL is then interpreted at runtime by DNA.

Re: JavaScript TC39 implementing hashmark private class fields

#74

Post by erikpukinskis »

ubertaco wrote: post #71
erikpukinskis wrote: post #62

Earlier quoted context omitted.

ES2015 classes are not easier to learn for newbies, they're easier to learn for Rubyists and other people coming from OO languages. There's nothing hard about this: function Person(name) { this.name = name } Person.prototype.greet = function() { return "Hi, "+this.name } var me = new Person("Erik") console.log(me.greet()) The syntax hurts your brain if you're used to looking at something else, but the control flow is…

Which is easier, explaining to your hypothetical total beginner what "Person.prototype" is and going down the rabbit hole of prototype-inheritance, and explaining how Javascript functions (unlike just about every other language's functions) can have attributes on them and can act like fake constructors and what "this" means in your example (and then later what it means in a different case, since it means so many diff…

You only think "class" is self explanatory because you already learned what it means.

Re: JavaScript TC39 implementing hashmark private class fields

#75

Post by erikpukinskis »

jhall1468 wrote: post #66
erikpukinskis wrote: post #62

Earlier quoted context omitted.

ES2015 classes are not easier to learn for newbies, they're easier to learn for Rubyists and other people coming from OO languages. There's nothing hard about this: function Person(name) { this.name = name } Person.prototype.greet = function() { return "Hi, "+this.name } var me = new Person("Erik") console.log(me.greet()) The syntax hurts your brain if you're used to looking at something else, but the control flow is…

There's zero magic. It is literally syntactic sugar and nothing else. Calling that magic is dishonest.

Ok, I can agree and I'll tighten up my use of "magic", reserve it for Railsy stuff where there's a lot of cpu cycles behind the scenes.

It's an extra layer of indirection that you can't see in the debugger though. Not sure what to call that.

I think calling me dishonest is a little strange. How is poor word choice dishonest?

Re: JavaScript TC39 implementing hashmark private class fields

#76

Post by erikpukinskis »

mercer wrote: post #70
just_astounded wrote: post #64

Earlier quoted context omitted.

I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and i…

Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.

Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern.

But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA.

Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new.

I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together.

I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns.

Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.

Re: JavaScript TC39 implementing hashmark private class fields

#77

Post by pjmlp »

gulbanana wrote: post #73
pjmlp wrote: post #67

Earlier quoted context omitted.

There is already a .NET prototype. https://github.com/SteveSanderson/Blazor https://www.youtube.com/watch?v=MiLAE6HMr10 WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well. As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.

blazor is not .NET compiled to WASM. blazor uses a .NET runtime called DotNetAnywhere, which is written in C and compiled with emscripten. the actual .NET IL is then interpreted at runtime by DNA.

True, but the fact is that people are already toying with the idea of bring such runtimes back into the browser.

Also if you bother to read the meeting minutes from WebAssembly meetings, developers from .NET team are present in such meetings.

Re: JavaScript TC39 implementing hashmark private class fields

#78

Post by just_astounded »

mercer wrote: post #70
just_astounded wrote: post #64

Earlier quoted context omitted.

I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and i…

Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.

There are a lot of reasons, honestly, and it's great beer conversation, but from a high level: producing a concrete instance that invokes a constructor function with a shiny pristine 'this' to build on is a pretty great pattern. Add the ability to muck about with clever prototype manipulation, and you have pretty enormous power - you can do everything that classic OOP can do (if that's your thing) and a lot more.

Re: JavaScript TC39 implementing hashmark private class fields

#79

Post by just_astounded »

pjmlp wrote: post #67
just_astounded wrote: post #58

Earlier quoted context omitted.

Until wasm has GC, we're not likely to see much in the way of compile-to-web outside of C, C++, or Rust.

There is already a .NET prototype. https://github.com/SteveSanderson/Blazor https://www.youtube.com/watch?v=MiLAE6HMr10 WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well. As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.

Fancy!

Re: JavaScript TC39 implementing hashmark private class fields

#80

Post by hajile »

barleymash wrote: post #72
hajile wrote: post #63

Earlier quoted context omitted.

Closures in JS are basically objects that have only one public property (called apply). Modern JITs are good at optimizing static objects (provided props are never added or deleted and the types never change). There is still (from what I remember) a small performance increase to normal objects, but it only becomes significant if you are creating hundreds or thousands of them. I'd say that in typical cases though that…

> Closures in JS are basically objects that have only one public property (called apply). Never heard it explained this way. Can you elaborate a bit? I'm not sure I follow. Couldn't a closure have any of the same properties that other functions have? Call, apply, bind, length, etc, etc.

When you execute a function, you set the program to execute the new function, but first, you take care of the related bookkeeping. A very important part of that is the function scope(s).

I'll first explain prototypical inheritance (because the two have close parallels). When you access a property in an object, a method runs behind the scenes. It does something like: search all the keys in the given object. If there is a matching key, return the value. If no such key exists, check for a __proto__ key. If it contains a value, call this function recursively on that object (and return whatever it gives back). If there is no __proto__ value, return `undefined`.

Let's assume an interpreter (to make it easy). Before we call a function, we need to setup the closure. The closure is an object with the names of all the variables you defined plus a few builtin things.

As we parse the function, any params, `var` or `function` statement creates an entries in the object. The values for the params are then pre-defined from the stuff provided by the caller. All the function statements are also pre-compiled. We add internal values for the return value, the parent closure (we'll call it __closure__), and some other things.

As the function runs, we come across a variable name. We then call a method to get it. That method searches the current scope for the name and returns the value. If none is found, it returns the result of calling itself on the __closure__ object. If no such object exists, it returns a `ReferenceError`.

Modern JITs do many fancy things with closures (just like they do with objects), but this basic mental model should cover most things.

Post reply on HN