News for hackers. Stuff that matters.

A comment on How JavaScript Works: deep dive into call, apply, and bind. Parent comment

Re:How JavaScript Works: deep dive into call, apply, and bind by user3939382 on Friday July 09, 2021 @06:00PM (#27789008)
I figure there’s 3 possibilities: I’m just dumb, I don’t use it enough, or JavaScript is poorly designed. For some reason, even after 20 years of using JavaScript on and off and reading a dozen books about it, I can’t articulate exactly how the language works, how scope is evaluated, the composition of objects and prototypes which has some kind of turtles-all-the-way-down thing going on with it. When I read explanations in books it’s like hmm ok.. I guess that makes sense. Then a week later I don’t remember. The languages I’ve spent the most time with are SQL, PHP, Bash, and Clojure, and I never felt that way about them. Maybe it’s just me.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by nicoburns on Friday July 09, 2021 @06:35PM (#27789286)
Prototypes are quite simple. An object may have a prototype. If it does then that prototype is just another object, which is considered the first objects parent (which works with method calls like class based inheritance). The chain ends because it's also possible for an object not to have a prototype.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by bluepnume on Friday July 09, 2021 @07:31PM (#27789650)
My advice is to start of with javascript by forgetting 100% about classes, inheritance, prototypes, and so on.

Just use vanilla functions and objects, and when in need of something that looks like a class, reach for the revealing module pattern:

https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4...

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by moron4hire on Friday July 09, 2021 @08:20PM (#27789929)
Not recommended if you have lots of objects with this interface. Each object will have its own copy of each function. Using a class with the methods in a prototype ensures there is only one copy for all object instances.

It also makes specialization and calling super methods super verbose.

And you've ultimately not done anything other than reimplementing OOP, poorly.

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by bokwoon on Friday July 09, 2021 @09:52PM (#27790457)
You're not supposed to use `super` or specialization with factory functions, call the functions you need instead.

OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by rustyminnow on Friday July 09, 2021 @07:52PM (#27789772)
I've used this pattern before, but run into issues when you want to write tests for "private" functions (like loadSong() in this example). What I've done is name them like _loadSong and expose them anyways, but that doesn't feel great.

Is there a better way?

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by moron4hire on Friday July 09, 2021 @08:21PM (#27789933)
You don't write tests for private methods.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by dotancohen on Saturday July 10, 2021 @02:20AM (#27791521)
Of course private methods should be tested. These are unit tests, not functional/integration tests.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by shawnz on Saturday July 10, 2021 @07:21AM (#27792631)
You don't unit test private methods, the "unit" is the exposed surface of the class.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by exdsq on Friday July 09, 2021 @11:59PM (#27791000)
Why not?
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by bmy78 on Saturday July 10, 2021 @07:45AM (#27792718)
Because it’s assumed those private methods’ usage happens within public methods, which should be tested. By testing the public methods and all of its use cases you are also testing private ones. That way you can arbitrarily modify private methods without touching the tests (presuming you’re refactoring and don’t need to modify behavior).
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by exdsq on Saturday July 10, 2021 @12:13PM (#27794384)
This seems to be building on rocky foundations though. It's unlikely a functions entire test vector gets checked during testing. This is a known risk (you can't test everything) but by leaving all the functions under a public function untested there is no safety net.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by moron4hire on Saturday July 10, 2021 @12:46PM (#27794677)
If the code of the private methods cannot be fully exercised through the class' public interface, then that code never executes and should not even be in the function.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by shawnz on Saturday July 10, 2021 @07:26AM (#27792646)
The most obvious reason is that they're private and not normally reachable from your test code.

But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by zebraflask on Friday July 09, 2021 @08:53PM (#27790141)
+1

Maybe I don't write very complicated material, but I can't think of a single time I've needed to use the more OOP features of JS because one of them was the best or only solution.

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by wruza on Friday July 09, 2021 @06:50PM (#27789408)
I also had this trouble, because for all other languages you can just tead the spec once and that’s it. But ES specs are too technical to be used as such. After few years I just read non-boring parts of ES6 and it cleared all dark corners.

I’d say all of the articles on the internet are rehashing the spec in (at best) a dubious and ritualistic way, and have zero technical value if you ask me.

[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by SPBS on Friday July 09, 2021 @09:46PM (#27790426)
FWIW the scoping in JavaScript is exactly the same in Go, so it's not something obscure that only JavaScript cooked up.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by orangecat on Friday July 09, 2021 @08:14PM (#27789891)
JavaScript is poorly designed. It was barely designed at all; Brendan Eich wrote it in ten days, and we would be better off if he had been a worse developer and hadn't been able to accomplish that. Instead Netscape shipped what should have been an internal 0.1, and got its deficiencies enshrined as documented features so they could never be fixed.
[ Parent | on HN ]
Re:How JavaScript Works: deep dive into call, apply, and bind by BrendanEich on Sunday July 11, 2021 @09:02PM (#27805853)
Ten day Mocha had strict ==, so better in that regard. History is detailed at https://youtu.be/krB0enBeSiE. Rather than assuming a too-simple version, check out the details for how things went down.

Do-overs not possible, by better new forms over time helped. Honest q: Do you actually use modern JS at all?

[ Parent | on HN ]