Re:The Future of JavaScript: What Awaits Us
by garyclarke27 on Wednesday August 20, 2025 @05:37AM
(#44960294)
Looks good but what about Named Parameters? Why on earth is Javascript still missing such an important feature? I know you can kind of fake it with objects, but is clunky in comparison.
Re:The Future of JavaScript: What Awaits Us
by dtagames on Wednesday August 20, 2025 @09:36AM
(#44961843)
That's actually a benefit. It allows the type signature to be used to compose and verify what you're passing to a function, and to use that same interface in other places.
Re:The Future of JavaScript: What Awaits Us
by Alifatisk on Wednesday August 20, 2025 @07:49AM
(#44960991)
I kind off don't see the point with Random.Seeded being part of Ecmascript? It's useful for sure, but isn't that something one could implement for themselves if needed? Is it really that sought after feature from the whole community?
Re:The Future of JavaScript: What Awaits Us
by rafram on Wednesday August 20, 2025 @10:06AM
(#44962114)
Why make people implement their own PRNG (in userspace code that’ll be slower than the built-in routine) for such a basic use case? I don’t know of any other major language in the world that doesn’t support setting the seed.
Re:The Future of JavaScript: What Awaits Us
by rafram on Wednesday August 20, 2025 @12:49PM
(#44963541)
> I suppose to not break existing code that implements a dispose method
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)
Also it is the same approach done in C and C++, another two languages where being clunky is a something we got used to.
I suppose to not break existing code that implements a dispose method, but it is a lot less friendly than regular method syntax.
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)