[HN Gopher] V8 Release v9.4
___________________________________________________________________
V8 Release v9.4
Author : feross
Score : 36 points
Date : 2021-09-06 17:48 UTC (5 hours ago)
(HTM) web link (v8.dev)
(TXT) w3m dump (v8.dev)
| franciscop wrote:
| I was expecting the blog post to have a bit more of substance
| after the introductory line:
|
| > V8 v9.4 is filled with all sorts of developer-facing goodies
|
| Instead it just describes a single feature, and then DIY:
|
| > Please use `git log branch-heads/9.3..branch-heads/9.4
| include/v8.h` to get a list of the API changes.
| ygra wrote:
| The DIY is apparently for people embedding V8, so the usual JS
| developer probably gains little from that list, anyway.
| magicalist wrote:
| > _all sorts of developer-facing goodies_
|
| From the posts in https://v8.dev/blog/tags/release, looks like
| the use the same opening paragraph every time. They should
| probably edit it or pick a default that doesn't promise so much
| :)
| franciscop wrote:
| That's an interesting template, wonder what happened here:
|
| v9.2: from V8's Git master
|
| v9.3: from V8's main Git branch
|
| v9.4: from V8's Git master
| simlevesque wrote:
| For more info on the new feature:
| https://2ality.com/2021/09/class-static-block.html
| geewee wrote:
| I honestly think the newer ECMAScript features with static
| blocks, private fields are a little strange. I get that some
| people _really_ want JavaScript to be object-oriented - but I
| wonder if we wouldn 't be better off embracing and building on
| its functional side.
| fiddlerwoaroof wrote:
| The worst part is that the syntax is designed to make JS look
| like other object-oriented languages without changing the
| prototypical object system to match the semantics of such
| languages.
| Waterluvian wrote:
| I'm perfectly happy for a language to have feature coverage for
| others to do what they like.
|
| I've found incredible success using JS (TS) as a functional
| language. Oh my god I love it. It's so easy to test. So easy to
| reason about. So predictable.
|
| State is my enemy. Optimization can be hidden away in the form
| of memoization rather than partially mutating object state.
|
| Does this work for all use cases? Nope. Classes are fine. They
| sure beat the five or so fake ways to do classes before ES6.
|
| I'll settle down now.
| xpressvideoz wrote:
| Some JavaScript people have been hostile to functional concepts
| since the beginning. See the missed opportunity to make Promise
| a monad.[1]
|
| [1] https://github.com/promises-aplus/promises-spec/issues/94
| Waterluvian wrote:
| I'm curious if someone can sell me, practically, in
| relatively few words, what that would gain us compared to
| Promises today.
|
| That link wasn't sufficient to teach me. I'm a bit dense. :(
| brundolf wrote:
| IMO classes are almost pointless without private fields; hiding
| state (in the handful of cases where that's really actually
| what you want) is one of their main legitimate uses
|
| But using static members in a language with module-level
| constants, functions, etc. just seems incredibly silly to me.
| And then expanding on that feature with exotic new syntaxes
| like this feels regressive.
| jancsika wrote:
| Yes!
|
| In Javascript I write a closure that returns an object full
| of methods.
|
| If I want private state I put the variables in that closure.
|
| Nothing bad has happened to me yet. :)
| LouisSayers wrote:
| Ah yes, the good parts :)
|
| I've found understanding exactly how JS works to become
| more confusing with class structures.
|
| It feels like you need a PHD in JS to have a good grip on
| how it all works under the covers.
|
| Using Crockfords closure strategy for me was quite
| straightforward and simple, and I've enjoyed doing:
|
| const MyClass = {}; MyClass.new = () => {}; const instance
| = MyClass.new();
|
| Which leaves all the "this." ugliness behind and provides a
| ruby-like instantiation.
| brundolf wrote:
| I would argue that that method (no pun intended) is less
| clear about intent and harder to read
|
| There are lots of things like this where the OOP version
| and the FP version are technically interchangeable in terms
| of capability, but not in terms of ergonomics or
| readability. A beautiful thing about working in a multi-
| paradigm language like JS is that you can reach across the
| aisle for the best tool for any given job. You can use
| classes to hide state, plain functions instead of statics,
| lambdas instead of anonymous classes, etc.
| antihero wrote:
| I wish they could add pattern matching statements.
| nicoburns wrote:
| Yeah, I find them utterly bizarre. I find it hard to believe
| that people using private implementation details is a real
| problem that people have. Underscore prefixing is a well-
| established convention within the JavaScript ecosystem, and
| with typescript it's easy to hide fields from the static types.
| I'm usually up for new language additions, but I can't see the
| benefit to this added complexity at all.
| vaughan wrote:
| It's driven by library developers wanting to prevent access
| to internals. I was annoyed by it initially because I love
| poking around in internals and it makes it easy to add
| missing functionality or fix bugs, but I can kind of
| understand from popular library maintainers.
|
| If Bar depends on a private internal of Baz, and Foo depends
| on Bar, then if Baz publishes a patch version that changes an
| internal to fix a bug, Bar breaks, and so does Foo.
| nicoburns wrote:
| I think React have the right approach. If something isn't
| part of the committed to public API, then it's named
| `__unstable_foo`. Consumers of the library are free to use
| them, but they can and will change at the whim of the
| maintainers regardless of any stability guarantees that the
| library usually provides.
|
| This allows advanced consumers to tinker where they need to
| and are prepared to take on the maintenance while leaving
| potential complainers no leg to stand on if the API
| changes.
| ectopod wrote:
| Can't you already hide your implementation details using a
| closure?
| kccqzy wrote:
| Yes you can. But few libraries actually do that.
___________________________________________________________________
(page generated 2021-09-06 23:02 UTC)