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

111–120 of 123 posts

Re: New Features in ES2019

#111

Post by sixbrx »

manigandham wrote: post #108
sixbrx wrote: post #106

Earlier quoted context omitted.

That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course…

Yes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem? If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a probl…

you've not addressed the points above, I'm out

Re: New Features in ES2019

#112

Post by manigandham »

sixbrx wrote: post #111
manigandham wrote: post #108

Earlier quoted context omitted.

Yes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem? If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a probl…

you've not addressed the points above, I'm out

There was no point other than incorrectly parsing a unix timestamp to something other than UTC. If you need to pass the time zone then pass it separately or use an ISO format instead. None of this is that complicated.

Re: New Features in ES2019

#113

Post by dwaite »

manigandham wrote: post #108
sixbrx wrote: post #106

Earlier quoted context omitted.

That's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course…

Yes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem? If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a probl…

I believe his point was that an instant in time (be it seconds since epoch or represented in some other way) is not the same as the representation of a calendar day - string-formatted standards let you represent concepts other than an instant.

The confusion might be coming from JavaScript incorrectly calling its instant representation Date, when it is actually quite a bit more precise than that.

Its also worth noting that you can't pick a time like 12:00 UTC and have it retain the calendar day in all time zones, because there are a few stray islands which are UTC+14 rather than UTC-10.

Re: New Features in ES2019

#114

Post by adev_ »

lightgreen wrote: post #102
mantap wrote: post #28

Earlier quoted context omitted.

The difference between JS and C++ is that C++ is addressing a complex problem domain whereas JS is addressing a simple one. So JS can put its complexity budget towards features that improve productivity whereas such features in C++ require huge amounts of complexity. Take for instance anonymous functions in JS compared with lambdas since C++11, the C++ version needs a complicated capture syntax, capability for captur…

> C++ version needs a complicated capture syntax C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases. C++ lambdas is another example where C++ committee chose complex uber-universal solution instead of much simpler which solves 99% use cases.

That's wrong.

C++ object lifetime management is much more tricky and error prone than the Rust one.

Passing an object by reference to lambda by default can be a beautiful source of out of scope and default.

The committee did an excellent job by allowing explicit filtering.

Re: New Features in ES2019

#115

Post by masklinn »

lightgreen wrote: post #102
mantap wrote: post #28

Earlier quoted context omitted.

The difference between JS and C++ is that C++ is addressing a complex problem domain whereas JS is addressing a simple one. So JS can put its complexity budget towards features that improve productivity whereas such features in C++ require huge amounts of complexity. Take for instance anonymous functions in JS compared with lambdas since C++11, the C++ version needs a complicated capture syntax, capability for captur…

> C++ version needs a complicated capture syntax C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases. C++ lambdas is another example where C++ committee chose complex uber-universal solution instead of much simpler which solves 99% use cases.

> C++ doesn't actually need it. Rust proved that capture everything by reference or capture everything by move is enough for all practical use cases.

That's kinda true but kinda not: precise "capture clauses" is a common design pattern in rust[0] showing that the flexibility is extremely useful, and I think I've seen rumblings about adding them to the language.

I mean technically you only ever need `move` closure, "ref" closures are already a convenience.

[0] http://smallcultfollowing.com/babysteps/blog/2018/04/24/rust...

Re: New Features in ES2019

#116

Post by masklinn »

manigandham wrote: post #112
sixbrx wrote: post #111

Earlier quoted context omitted.

you've not addressed the points above, I'm out

There was no point other than incorrectly parsing a unix timestamp to something other than UTC. If you need to pass the time zone then pass it separately or use an ISO format instead. None of this is that complicated.

The point is that a date is not the same thing as an instant. A unix timestamp captures an instant, but that may not be suitable or desirable to a specific use case e.g. instants are usually broken when it comes to scheduling future events as the mapping might change inbetween the recording and occurrence, and you want this change to be reflected on your execution.

Re: New Features in ES2019

#117

Post by masklinn »

javajosh wrote: post #96

Good stuff! Normally I cringe to see new language features, but these are pretty good (Java after lambdas, even arguably after generics, is pretty crufty, IMHO) One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things. I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to…

> One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things.

Not sure what strange things it does. fromEntries simply takes each entry, sets its first item as key (stringifying if necessary as object keys are necessarily strings) and the second item as value. Naturally falls from these that a null or undefined entry will error, and an empty entry will create an {undefined: undefined} item.

> I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to skip an entry and the easiest way to do this is just return `undefined`.

Use flatMap instead?

Re: New Features in ES2019

#118

Post by goto11 »

recursive wrote: post #94
goto11 wrote: post #69

Earlier quoted context omitted.

If it doesn't make any difference if the code inside the try block is executed or not, why even have the code in the first place? What is the use case for a try without a catch?

Opportunistically loading from a cache

But if loading data from the cache fails, wouldn't you have to do something else to get the data? Or am I misunderstanding?

Re: New Features in ES2019

#119

Post by agumonkey »

bokchoi wrote: post #73
agumonkey wrote: post #37

Earlier quoted context omitted.

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

Does anyone use edn or transit outside of the clojure ecosystem?

I remember seeing the idea pitched somewhere (maybe some SO thread or like that)

Re: New Features in ES2019

#120

Post by javajosh »

masklinn wrote: post #117
javajosh wrote: post #96

Good stuff! Normally I cringe to see new language features, but these are pretty good (Java after lambdas, even arguably after generics, is pretty crufty, IMHO) One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things. I wrote an `mapObject` function that looks like `(a,fn) => Object.fromEntries(Object.entries(a).map(fn))` and occasionally the fn needs to…

> One thing I'd to request is that `Object.fromEntries()` simply skip undefined entries, rather than do...strange things. Not sure what strange things it does. fromEntries simply takes each entry, sets its first item as key (stringifying if necessary as object keys are necessarily strings) and the second item as value. Naturally falls from these that a null or undefined entry will error, and an empty entry will creat…

Yes, it errors out. And flatMap isn't applicable here. Here's some complete test code you can try in your browser right now:

``` let p = (a,fn) => Object.fromEntries(Object.entries(a).map(fn)) p({a:1, b:2}, ([k,v])=> v === 2 ? undefined : [k,v]) ```

My intent is to skip the entry with `b:2`. However, both map and flatMap error out. It would be nice if `fromEntries` did what I think is the appropriate thing, which is just skip undefined and null. Is this not the behavior you'd expect?

Note that without special treatment in fromEntries, there's no way for the mapping function to indicate "skip this entry". You have to do it in another pass, or some other way.

Post reply on HN