I might be wrong but I'm pretty sure the method `return` and `throw` are part of the Generator's spec and not Iterator's. Also Generator's `next` takes an argument while Iterator's doesn't. Most structure expecting an "Iterator" usually uses the Generator method so if you had to implement one manually, sticking to the Generator specs makes sense. There is one use case were I find a difference through: if you share an Iterator between multiple loops (ad hoc queue/multi consumers), any loop breaking will causes a call to Generator's `return` method which will put the generator in a done state and end the other loop (no more value). If you have an iterator, there is no `return` method and the other loop will exhaust the iterator.
There is no need to call super if you’re talking about the Dog question. There isn’t any inheritance happening, so calling super in the constructor would be pointless it seems.
I’ve been working as a full stack dev for over 2 years now and I’ve never had to dive this deep. Am I doing something wrong ? I’m genuinely curious how this is useful in the real world if you’re not building apps from scratch
ehm, well promises are basically everywhere, classes are very useful in ts, and iterators are used under the hood of good old sagas, well that's basically single place I've come by iterators but anyway quite a handy base to build on
She basically has a quiz that are very similar to the questions I ask candidates when hiring other web developers during the theory interview round. I’m an architect at a fortune 30 company in finance, one of the top two banks in the world for reference. I’ll be checking this out, God willing. Seems like a lot of fun!
@@thi-m10 the question from video is a good example to understand the fundamentals as a fun exercise, but it's very terrible as an interview hard requirement test. It could be fun practice/warm up for both candidates and interviewer to go through the questions, but imply it's not a real thing to test against you. If you used this types of tricky code a lot in your codebase and it's the reason why you test the candidate. As a senior or whatever developer/interviewer you should be shameful for whatever you are doing now without good reasons. Speaking from the experience of that many cool kids know this type of tricky questions, neglect the fundamental, and actually try to apply them in real practice. Just like applying some crappy leetcode algos for simple stuffs. It's such a nightmare. The worst part, some senior devs are truly pretentious about knowing them, even some hacky prototype behavior you should never know or use, or terrible JavaScript design mistake from the past, which is completely irrelevant outside of JS.
