Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Features in ES2019

javascript.christmas

Post reply on HN
Print view View original

31–40 of 123 posts

Re: New Features in ES2019

#31

Post by chrismorgan »

[This comment is wrong; see masklinn’s response for my misunderstanding.]

> Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code:

> JSON.stringify('\uD83D');

> // '"\\ud83d"'

I’m inclined to consider this a misfeature, unbreaking something that I’m glad was broken and should have remained broken.

Unpaired surrogates are (to simplify terminology a little) basically invalid Unicode. On the web platform, the only situation where unpaired surrogates should be encountered is as a transient state on user input, on platforms that send non-BMP characters through in two pieces (which is most browsers on Windows). Beyond that, nothing should ever deal in unpaired surrogates, because they will make things blow up and your life miserable.

Unpaired surrogates cannot be represented in UTF-8, or in well-formed UTF-16 (and that’s where JavaScript did the annoyingly bad thing that we’re paying for decades later, going with UTF-16 and not requiring well-formedness). Hence I’d quibble with the description of the result as “valid UTF-8/UTF-16 code”. (Sure, the actual JSON byte stream will be valid, but it contains an escaped string that is not valid.) U+FFFD REPLACEMENT CHARACTER was at least as valid, arguably more valid.

Various JSON parsers will choke on such strings, as observed in what I’d consider the canonical JSON spec: https://tools.ietf.org/html/rfc7159#section-8.2.

In the I-JSON restricted subset, which is what I’d say everything should actually limit itself to, such strings are disallowed and will cause parse failure: https://tools.ietf.org/html/rfc7493#section-2.1.

Re: New Features in ES2019

#32

Post by pythux »

masklinn wrote: post #22
pythux wrote: post #11

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScri…

> One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?). New methods with simple behaviour don't really make the language more complex through. > And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start. As you note it kinda does, just in a weird roun…

> New methods with simple behaviour don't really make the language more complex through.

I think they do, in some ways. If you have multiple methods or functions which seem to do similar things, as a new-comer it can be incredibly confusing. I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences. I agree that it might be less ambiguous between "replace" and "replaceAll", but I think over time these things matter.

Re: New Features in ES2019

#33

Post by tiborsaas »

IgorPartola wrote: post #16

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

You don't need to parse when getting data, the fetch API does that for you automatically.

    const res = await fetch(url);
    const data = await res.json();
For posting you do need JSON.stringify(data), but I never thought of it as painful, just a single line.

Re: New Features in ES2019

#34

Post by alkonaut »

Legogris wrote: post #29
alkonaut wrote: post #10

Earlier quoted context omitted.

It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. If the comparison function argument was mandatory in sort() this wouldn’t be a problem.

A different comparison function would not make efficient QuickSort stable.

It’s not the stability that bothers me but the fact that the comparison function is implicit and basically is

(a, b) -> a.toString().compareTo(b.toString())

Unlike say int.parse() where 10 is a reasonable default for radix, doing string comparison as default is almost never what the caller wants, so is a bad default. Functions where there is no obvious (99% of the time the desired value) should not have a default value when the argument is omitted. I’d much rather have things.sort() just fail and force me to specify the comparison, than to see it sort alphabetically.

As a side note: a second optional argument specifying stability true/false would be reasonable. True could be the default too, since unstable sorting is effectively an optimization with a tradeoff.

Re: New Features in ES2019

#35

Post by masklinn »

pythux wrote: post #32
masklinn wrote: post #22

Earlier quoted context omitted.

> One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?). New methods with simple behaviour don't really make the language more complex through. > And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start. As you note it kinda does, just in a weird roun…

> New methods with simple behaviour don't really make the language more complex through. I think they do, in some ways. If you have multiple methods or functions which seem to do similar things, as a new-comer it can be incredibly confusing. I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were th…

> I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences.

Possibly aside from the latter (assuming you mean Array#forEach), these are not different "methods with simple behaviour", they're different language constructs with largely overlapping behaviour & use cases.

Re: New Features in ES2019

#36

Post by wongarsu »

dmit wrote: post #25
mikece wrote: post #20

Earlier quoted context omitted.

I was going to ask a variant of that question: what is the status of BigInt and when might it clear TC39 approval? In most languages a Date object is just a BigInt with Unix time() making this somewhat obvious. BigInt will allow not only proper Date implementation but Currency and Real types, and many more things.

If by BigInt you mean an arbitrary-precision integer type, then AFAIK no major language uses it to represent dates. If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.

I would argue dates with nanosecond granularity are of limited usefulness. In almost all use cases millisecond granularity is sufficient for dates, if you need nanosecond granularity chances are you also want a monotonic clock instead of real time that's subject to daylight savings, NTP correcting the clock etc.

Re: New Features in ES2019

#37

Post by agumonkey »

IgorPartola wrote: post #16

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

Clojure devs tried to make something like that with edn and transit IIUC

Re: New Features in ES2019

#38

Post by masklinn »

chrismorgan wrote: post #31

[This comment is wrong; see masklinn’s response for my misunderstanding.] > Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code: > JSON.stringify('\uD83D'); > // '"\\ud83d"' I’m inclined to consider this a misfeature, unbreaking something that I’m glad was broken and should have remained broken. Unpaired surrogates are (to…

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate.

That is, formerly U+D83D would pass through straight as U+D83D (or possibly be replaced by U+FFFD in some implementations), whereas it is now "encoded" as the sequence U+005C U+0075 U+0044 U+0038 U+0033 U+0044.

That is, the entire point of the "well-formed stringify" proposal[1] was to stop generating broken JSON:

> Rather than return unpaired surrogate code points as single UTF-16 code units, represent them with JSON escape sequences.

[0] it's possible that some implementations would replace the lone surrogate by U+FFFD but according to MDN:

> Before this change JSON.stringify would output lone surrogates if the input contained any lone surrogates; such strings could not be encoded in valid UTF-8 or UTF-16

this is also the behaviour I observe on an old safari, and the one which is quoted in the tc39 proposal[1]:

> JSON.stringify can return strings including code points that have no representation in UTF-8 (specifically, surrogate code points U+D800 through U+DFFF). And contrary to the description of JSON.stringify, such strings are not "in UTF-16" because "isolated UTF-16 code units in the range D800₁₆..DFFF₁₆ are ill-formed" per The Unicode Standard, Version 10.0.0, Section 3.4 at definition D91 and excluded from being "in UTF-16" per definition D89.

[1] https://github.com/tc39/proposal-well-formed-stringify

Re: New Features in ES2019

#39

Post by matsemann »

nkozyra wrote: post #30
Nullabillity wrote: post #18

Earlier quoted context omitted.

If I remember correctly, AngularJS 1.x would use it for dependency injection.

How so? Were these eval()ed by Angular? I don't follow what it would use function strings for determining missing - presumably - polyfills that you couldn't do in better ways.

In angular 1, if you had a function on the form

  myApp.controller('MyCtrl', function($myCoolService) {
    //...
  });
Angular would see that you are looking for a parameter named myCoolService, see if it already has it, and then inject it when calling your controller.

This of course broke in various ways with minification when the parameter names were mangled. So one had the opportunity to use "array syntax", requesting a dependency by a string. Or use a preprocessor in the build script adding the array syntax before minifying.

Re: New Features in ES2019

#40

Post by [deleted] »

masklinn wrote: post #38
chrismorgan wrote: post #31

[This comment is wrong; see masklinn’s response for my misunderstanding.] > Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code: > JSON.stringify('\uD83D'); > // '"\\ud83d"' I’m inclined to consider this a misfeature, unbreaking something that I’m glad was broken and should have remained broken. Unpaired surrogates are (to…

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate . That is, formerly U+D83D would pass…

[deleted]
Post reply on HN