Amusing bug: console.log(`Average height for dogs is ${AVERAGE_HEIGHT_FT} kg`); Height in kg? ;D
Those are feet kgs. Like light years.
It says the average weight is 100 kg so these are some pretty big dogs. I’d expect each foot to be a kg.
How to rewrite classes using closures in JavaScript
31–40 of 58 posts
Re: How to rewrite classes using closures in JavaScript
#32There are several points in the article which are just plain wrong: - no private properties ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ) - no readonly properties: You can use a getter. Or define the property as non-writable, the syntax isn't nice but in my opinion it's still much nicer than what the article proposes. Some of the points are just a matter of taste ("this" is awkward) There's the…
Agreed. I spent a small epoch of my career trying to make js have "classes" in the heady days of OOP. It took a bit to realize that idiomatic js didn't need them. Besides being sold so hard on OOP as a concept, failing to understand prototypes was one of my biggest mistakes. By the time they landed, I was actually pretty disappointed to see the language get classes.
Re: How to rewrite classes using closures in JavaScript
#33I wonder if React has had any impact on people's general tendency for reaching for classes vs. closures, particularly after hooks were introduced.
Thing is, hook state looks like closures, but it's not the same at all.
The machinery behind the scenes might be ugly, but this syntax is also what I love about React Hooks.
I was preferring closures to ES6 classes before using React, despite the performance implications.
Since switching to TypeScript I also like ES classes though.
Especially for things like MobX... but even without it.
Regardless of React, I feel like classes are the context where getters and setters feel most natural and ergonomic.
And classes are great for grouping state and behavior in an easy-to-understand way.
Re: How to rewrite classes using closures in JavaScript
#34I wonder if React has had any impact on people's general tendency for reaching for classes vs. closures, particularly after hooks were introduced.
I think it made using classes more popular before hooks, and drove--along with functional components--the more general popularity of functional style of js afterwards. I feel like the latter are the idioms you will find most common in modern code, docs, and training today; though class components are still fully supported.
Re: How to rewrite classes using closures in JavaScript
#35Lord, no, please, please don't do this in any codebase that anyone else has to actually look at/contribute to.
Other commenters have pointed out some of the technical issues with this implementation (all instances get a copy of every method, no prototype-based type checking, non-standard use of "init" vs new, etc.) But the much more important issue is that you did not make life easier for other developers looking at your code. Instead, you just forced them to learn one additional, non-standard way of doing things with very little, if any, real benefit.
Developers need to learn to be extremely judicious whenever you use unusual/non-standard patterns in code. Everyone already needs to learn the standard way of doing things, so there should be a giant bar in terms of things like productivity enhancements or performance improvements if you're forcing everyone to learn your non-standard pattern. Avoiding "this" doesn't cut it.
Re: How to rewrite classes using closures in JavaScript
#36There are several points in the article which are just plain wrong: - no private properties ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ) - no readonly properties: You can use a getter. Or define the property as non-writable, the syntax isn't nice but in my opinion it's still much nicer than what the article proposes. Some of the points are just a matter of taste ("this" is awkward) There's the…
Agreed. I spent a small epoch of my career trying to make js have "classes" in the heady days of OOP. It took a bit to realize that idiomatic js didn't need them. Besides being sold so hard on OOP as a concept, failing to understand prototypes was one of my biggest mistakes. By the time they landed, I was actually pretty disappointed to see the language get classes.
> By the time they landed, I was actually pretty disappointed to see the language get classes.
TBF classes are just a layer of syntactic sugar over the (awful) prototypal system (which somewhat sadly few were interested in making better let alone good).
Behind the scenes, they pretty much just create a ctor function and prototype function, except you don't have to mess with the terrible `Object.create` and `.prototype =` nonsense.
Abandoning constructors and going full-on with prototypes would be an other thing entirely, but the reality is that javascript is not very good at it so it's not very fun (except as a proof of concept / investigation of prototype based OO), and pretty much nobody is interested.
Re: How to rewrite classes using closures in JavaScript
#37Classes are just synthatic sugar over closures anyway. The benefit of OOP classes is that they can be extended. But closure cannot.
Re: How to rewrite classes using closures in JavaScript
#38Private and readonly properties are 100% possible on classes, and you don't even need the newfangled private property syntax! You can roll it your own easily, and all you need is WeakMap. Unfortunately nobody seems to understand what weak maps are for...
Here's the example code: https://gist.github.com/conartist6/95f5be3488b2ae6c0dfd9a886...
Re: How to rewrite classes using closures in JavaScript
#39There are private properties in classes class Foo { #ImPrivate = true; #meToo() { if(this.#ImPrivate) cantTouchThis(); } } new Foo().#meToo() === BOOM Also with using closures for "classes" takes up a whole lot more memory because new instances off all the closures are created for each instance of the class.
Private properties don't work with Proxy. https://lea.verou.me/blog/2023/04/private-fields-considered-... Quote: > Private fields, proxies, pick one, you can’t have both.
For the same reason, they are forbidden in MobX.
Hello underscore!
And thank god for TypeScript compiler's private keyword! While... I can see how this plethora of possibilities looks confusing.
Re: How to rewrite classes using closures in JavaScript
#40IMO before the before and after patterns are a mess compared to a struct in Rust etc or a dataclass in Python. `this` or `self` is important to be explicit; C++ is an interesting case in that it gives you a choice; `this->` is the better approach than implicit, which is ambiguous.
I can't tell from a glance from either before or after what the fields of the class are, let alone what sort of data goes in them. I suspect my IDE would have a struggle as well, and allow mistakes, at runtime, to either raise exceptions, or perform incorrect behavior.
I think maybe a cleaner approach in this domain may be TS interfaces + standalone functions that act on them.