| 00:08 | <bradleymeck> | so if species doesn't work core-js will polyfill it with a impl that does make it work, https://github.com/zloirock/core-js/blob/master/packages/core-js/modules/es.promise.js#L256 |
| 01:50 | <shu> | bradleymeck: make it work purely in user land? |
| 02:50 | <bradleymeck> | It does, but has a minor bug with promise.finally polyfills detection not caring about species |
| 03:09 | <shu> | fascinating |
| 03:10 | <shu> | so if engines turn off subclassing sites might break not because they depend on it but because the corejs polyfill will suddenly kick in for promises |
| 03:12 | <rkirsling> | maybe it's still okay as long as the polyfill is spec-perfect? |
| 03:13 | <devsnek> | bradleymeck: what's the bug in promise.finally? the polyfill doesn't appear to touch it |
| 03:13 | <devsnek> | and finally calls .then so |
| 03:14 | <bradleymeck> | Separate file, basically just checks if it can be called with 2 arg params |
| 03:15 | <bradleymeck> | If it can't (such as missing) it replaces it with a species thing |
| 03:15 | <shu> | rkirsling: yeah one can hope |
| 03:16 | <bradleymeck> | https://github.com/zloirock/core-js/blob/master/packages/core-js/modules/es.promise.finally.js#L20 |
| 03:18 | <shu> | what’s the use case of corejs today |
| 03:18 | <shu> | es6 has been a few years |
| 03:18 | <devsnek> | my understanding is that it gets injected by babel |
| 03:19 | <devsnek> | to polyfill modern features and fix bugs |
| 03:19 | <shu> | i’m curious about the es6 era stuff, which are arguably no longer modern |
| 03:20 | <devsnek> | well i mean if you're targeting ie8 |
| 03:21 | <devsnek> | i think babel-preset-env will stick in stuff like import { Promise } from 'core-js' |
| 03:23 | <shu> | does anything get dropped from it? |
| 03:23 | <devsnek> | wdym "dropped" |
| 03:24 | <shu> | has any feature been removed from corejs because of widespread native support? |
| 03:24 | <shu> | or is its mandate to shim all post es5 features? |
| 03:25 | <devsnek> | oh i have no idea |
| 03:26 | <devsnek> | it looks like it might even polyfill the JSON global? |
| 03:26 | <devsnek> | which would be what, pre es5? |
| 03:26 | <ljharb> | shu: there's still a large case for es6 polyfills |
| 03:26 | <ljharb> | shu: and there's still large usage of older browsers. |
| 03:27 | <ljharb> | and no, neither core-js, nor any of my stuff in the es-shims family, have or ever likely will "drop" anything |
| 03:27 | <ljharb> | altho i'm sure there's stuff that hasn't been gotten around to yet |
| 03:31 | <shu> | ljharb: how much older are we talking? |
| 03:31 | <ljharb> | all my shims work in IE 6 |
| 03:32 | <ljharb> | (up to the limit of the engine; obv getters/setters requires native support, etc) |
| 03:32 | <ljharb> | as far as usage, IE 9 is still frequent enough to warrant shimming |
| 03:32 | <rkirsling> | MS had that eradication campaign years ago though |
| 03:32 | <rkirsling> | yeah IE9 I'll believe |
| 03:32 | <devsnek> | don't south korean banks have to use ie9 or 11 or smth |
| 03:32 | <ljharb> | they didn't support newer IE on old enough windows to make that useful |
| 03:32 | <ljharb> | IE 6-8 is largely dead because of SSL stuff |
| 03:33 | <shu> | SK banks are heavy users of activex is what i recall |
| 03:34 | <rkirsling> | still can't shake how weird it is to have such technology be gov't-mandated |
| 03:34 | <devsnek> | it happens in the US too |
| 03:34 | <shu> | ljharb: how do you run ie6 to check support? |
| 03:34 | <devsnek> | we used to have to maintain FIPS compliance in node's crypto module |
| 03:34 | <ljharb> | shu: either via browserstack, or via the windows VMs that microsoft has distributed for that purpose for years |
| 03:35 | <shu> | i see |
| 03:35 | <rkirsling> | I mean compliance is not gonna be avoidable but it was literally "you have to use IE" no? |
| 03:36 | <rkirsling> | (unless that was just the effect of whatever the law actually said) |
| 03:37 | <devsnek> | i'm def not an expert on SK law |
| 03:37 | <devsnek> | but i believe they had to use certain software to be in compliance (activex things) and that only works in old ie |
| 03:37 | <Bakkot> | a lot of the use of IE9 is employers who mandate it, which is in some ways similar |
| 03:38 | <shu> | ljharb: just for your own packages, you don’t plan to drop eg ie6... ever? |
| 03:39 | <shu> | or until MS makes it impossible to even run, or other considerations? |
| 03:40 | <ljharb> | shu: i don't see much value in doing so. it's already both necessary and relatively trivial to swap out packages in the ecosystem as part of your build process when your supported browsers no longer need them |
| 03:41 | <ljharb> | the other thing is, the delta between "works in IE 6" and "works in IE 9", or "works in IE 11" is actually pretty small |
| 03:41 | <ljharb> | also it's not just IE. "old android" is a massive offende |
| 03:41 | <ljharb> | r |
| 03:41 | <devsnek> | pre 4.4? |
| 03:41 | <ljharb> | and Opendoor had significant traffic from Safari 6. |
| 03:41 | <ljharb> | devsnek: yes |
| 03:41 | <devsnek> | :( |
| 03:41 | <ljharb> | airbnb could afford to drop IE 9, because its marginal income per visitor was tiny |
| 03:42 | <ljharb> | but opendoor could earn 100k from any *one* visitor |
| 03:42 | <ljharb> | and safari 6 was like 2-3% of all traffic |
| 03:42 | <shu> | compelling |
| 03:43 | <ljharb> | also, tons of people are on "not latest" chrome and firefox |
| 03:43 | <ljharb> | "autoupdate means everyone is up to date" is a huge lie |
| 03:43 | <shu> | that is certainly true |
| 03:43 | <devsnek> | https://gc.gy/57910391.png |
| 03:43 | <shu> | i was wondering more about being 5+ years out of date |
| 03:43 | <ljharb> | devsnek: rimshot |
| 03:43 | <shu> | my working assumption is usually 5 years |
| 03:43 | <ljharb> | shu: 5 years ago, zero browsers were fully ES5 compliant. |
| 03:43 | <ljharb> | shu: let alone ES6 |
| 03:43 | <ljharb> | shu: the last 2-4 years has been amazing for compliance tho |
| 03:44 | <shu> | my internal doc is called “operation extinction” |
| 03:44 | <devsnek> | lol |
| 03:44 | <devsnek> | ever since browsers transitioned to the evergreen idea its been fantastic |
| 03:44 | <ljharb> | nothing like finding a kind of genocide that makes everyone happy |
| 03:44 | <devsnek> | moving to new systems like turbofan to make shipping features easier |
| 03:44 | <ljharb> | devsnek: post-auto-update tho, there's still *tons* of people who don't update |
| 03:45 | <shu> | ljharb: i’m aware of that |
| 03:45 | <ljharb> | autoupdate doesn't work if their hard disk is full of viruses and photos :-p |
| 03:45 | <shu> | who are the folks who have not updated software in 5 years |
| 03:45 | <devsnek> | my grandma was using 5 year old firefox |
| 03:45 | <ljharb> | turns out, lots of people that own a home and want to sell it |
| 03:45 | <devsnek> | until a few days ago |
| 03:45 | <devsnek> | when i told her she should update it |
| 03:46 | <shu> | well i’m sure we have stats for this but i am too lazy to get my laptop |
| 03:46 | <ljharb> | i also often talk to older folks that don't know how to update, and also think machines shouldn't be replaced more often than every 7-10 years |
| 03:46 | <shu> | hardware replacement is synonymous with downloading new software for them? |
| 03:47 | <ljharb> | lol no, but i mean that they're also on older machines |
| 03:47 | <ljharb> | that don't often support newer OS's, and thus browsers |
| 03:47 | <ljharb> | when things don't support far enough back, it doesn't encourage users to update, it just encourages them not to stir the pot |
| 03:47 | <ljharb> | nobody wants to fix what ain't broke |
| 03:48 | <ljharb> | (also, when certain website just don't work, they think it's their fault, and are embarrassed to ask for help and thus find out that it's not their fault, they just need to update) |
| 03:48 | <shu> | so i’m not really asking for anecdotes for people who don’t update software, i know that is true |
| 03:48 | <ljharb> | lol k sorry |
| 03:49 | <shu> | i guess i am surprised that half a decade of not stirring the pot still gives people enough working parts they can do useful things, like go to airbnb.com |
| 03:50 | <shu> | but really, i shouldn’t be |
| 03:50 | <devsnek> | i wonder how far back google.com works |
| 03:50 | <shu> | i think the main page should work for basically anything |
| 03:50 | <rkirsling> | mosaic or bust |
| 03:51 | <devsnek> | well you do get cut off by tls |
| 03:51 | <shu> | in another 20 years i should like to commission a study on if the web platform was one big moral hazard |
| 03:52 | <devsnek> | lol |
| 03:54 | <rkirsling> | snort |
| 03:58 | <Bakkot> | shu: I think there's a lot of people on > 5 year old phones, esp. outside of America |
| 03:59 | <shu> | ah, and once the OEM stops support and no more over the air updates, software is frozen? |
| 04:00 | <devsnek> | a lot of the cheap ones never get updates in the first place |
| 04:01 | <devsnek> | this is why android is moving to the modular setup where they can push security updates and stuff through the play store |
| 04:02 | <Bakkot> | shu yup |
| 04:02 | <Bakkot> | and as devsnek says "OEM stops support" is often very soon after the phone is released |
| 04:03 | <devsnek> | even flagship droids can have spotty updates |
| 04:03 | <shu> | economics of it makes sense |
| 04:04 | <devsnek> | well its only a problem because they all feel the need to add their weird patches into the kernel |
| 04:04 | <devsnek> | then lo and behold updating those patches is hard |
| 04:05 | <shu> | i’ve heard funny stories from the art (android runtime) vm team about working around buggy OEM vms that crash on specific opcode sequences |
| 04:05 | <shu> | so you need to generate certain magic incantation gadgets for certain phones |
| 04:05 | <devsnek> | aw man |
| 04:07 | <Bakkot> | reminds me of https://twitter.com/XMPPwocky/status/1261130110003843073 |
| 04:08 | <devsnek> | :( |
| 04:14 | <rkirsling> | I genuinely hate machines |
| 04:14 | <rkirsling> | lol |
| 04:16 | <ljharb> | that is an amazing thread |
| 04:46 | <rkirsling> | ljharb: braces had nothing to do with what that guy was saying :- |
| 04:47 | <rkirsling> | :-/ |
| 04:47 | <rkirsling> | the `if` was purely incidental |
| 04:49 | <ljharb> | lol maybe but i can't understand the thesis of an essay that has spelling and grammar errors, they're too distracting |
| 04:51 | <rkirsling> | I mean it's pretty inflammatory to suggest that dropping braces isn't a valid style choice though |
| 04:52 | <ljharb> | i don't see why, that's what caused heartbleed |
| 04:52 | <ljharb> | i'd say it's a pretty bold claim to say that omitting them is safe |
| 04:52 | <rkirsling> | there's nothing hard to read about a two-line code example that doesn't use braces on a if |
| 04:52 | <rkirsling> | I don't know what to say |
| 04:53 | <rkirsling> | it's webkit style to always drop them for a one-line body |
| 04:53 | <ljharb> | i'll hide my comment tho, since they edited the result |
| 04:53 | <ljharb> | rkirsling: sure. from what i recall, webkit's style isn't what i'd call consistently readable anyways :-) (that's subjective, ofc) |
| 04:53 | <ljharb> | it's not uncommon to drop them for a *same*-line body tho |
| 04:53 | <rkirsling> | I mean it's extremely consistent so I don't know why you wouldn't call it readable |
| 04:53 | <ljharb> | consistency alone does not readable make |
| 04:53 | <rkirsling> | consistency is the important part |
| 04:54 | <ljharb> | it's a minimum, but not sufficient, requirement |
| 04:54 | <rkirsling> | I mean this isn't about what one would recommend a codebase do |
| 04:55 | <rkirsling> | it truly had nothing to do with anything here... |
| 04:55 | <ljharb> | sure, agreed |
| 04:55 | <ljharb> | i just couldn't tell because the if statement distracted me |
| 04:56 | <rkirsling> | I actually thought the density of the original example was the strength of it |
| 04:57 | <ljharb> | for me, the modified version makes the point clearly, and i totally missed it in the original one ¯\_(ツ)_/¯ |
| 04:57 | <rkirsling> | i.e. "it would be easy to get lost reading this without making the placeholders explicit" |
| 04:57 | <rkirsling> | now I'm not sure it's making a point at all |
| 04:57 | <ljharb> | tbh i still can't remember which name goes with which style, nor have i totally made up my mind as to which form i prefer |
| 04:57 | <rkirsling> | though (8) is its own valid point |
| 04:57 | <ljharb> | and those threads are often full of people who perceive every comment as a threat to their preferred style |
| 04:58 | <rkirsling> | he's arguing for the latter, not the former |
| 04:58 | <ljharb> | gotcha |
| 04:58 | <rkirsling> | which is why I said the point got lost in the cleanup |
| 04:59 | <ljharb> | hm, maybe so |
| 04:59 | <ljharb> | clearly i missed the point in both cases, then |
| 05:02 | <shu> | Bakkot: you know who else loves utf16... |
| 05:55 | <Bakkot> | shu: is it javascript |
| 05:56 | <Bakkot> | I feel like if JS loved UTF-16 it would have had UTF-16 in it somewhere, instead of the unholy thing we have |
| 15:41 | <Bakkot> | ljharb: re: https://github.com/tc39/proposal-promise-any/issues/38 |
| 15:42 | <Bakkot> | it looks to me like everyone has said the things they have to say and everyone except you still wants it to be an own property |
| 15:42 | <Bakkot> | would you be willing to let it go so that the proposal can ship? |
| 15:42 | <Bakkot> | cc mathiasbynens ^ |
| 16:10 | <ljharb> | No, I’d like it discussed in plenary. It already has consensus as it is. |
| 16:33 | <Bakkot> | OK, I guess we can put something on the agenda. |
| 16:33 | <Bakkot> | I don't know what the benefit of that discussion will be though. |
| 16:33 | <Bakkot> | What benefit do you see in having the discussion there? |
| 16:34 | <Bakkot> | Except that we can put it to a vote if discussion fails again, I guess. |
| 17:24 | <shu> | i also believe that discussion won’t be a good use of plenary time |
| 17:30 | <shu> | ljharb: without new insight, and i know your position on voting, it’s unclear to me too what you want that agenda item to do |
| 21:00 | <ljharb> | gather opinions from those not present in the github thread |
| 21:01 | <ljharb> | mark gave consensus for the current approach, and seems to have changed his mind in the thread; as have others; i'm interested to know what the broader committee thinks about own data vs prototype accessor properties in a case like this |
| 21:01 | <ljharb> | there's a lot of places in es6 that changed to be prototype accessors, and i'd been under the impression that was an intentional philosophical trend |
| 21:05 | <ljharb> | in particular, changes in stage 3 generally are supposed to be those that arose from implementor or user feedback, that weren't considered previously. it was reopened with what seems to me like stage 2 design considerations (ones i don't agree with). i don't recall seeing any strong argument that a change is more implementable than the current spec - if i missed one, can you point me to it? |
| 21:32 | <devsnek> | do any of the accessors we currently have return mutable structures |
| 21:34 | <ljharb> | nope, they all happen to return primitives atm |
| 21:36 | <ljharb> | everyone seems on board with primitive properties being accessors on the prototype; the own primitive properties are that way because legacy. this is just the first time an object property on an instance has come up afaik |
| 21:53 | <Bakkot> | I am not really on board with primitive properties being accessors on the prototype if there is not some underlying state they reflect which is otherwise available |
| 21:54 | <Bakkot> | I think it makes sense to use prototype accessors iff the information they give you is reflected elsewhere |
| 21:54 | <Bakkot> | if the property itself is all the data there is, I do not |
| 21:54 | <Bakkot> | (as I said in the thread) |
| 21:56 | <Bakkot> | ljharb: also fwiw I am the one who asked for stage three with accessor on prototype, and I regret doing so |
| 21:57 | <ljharb> | what do you mean by "reflected elsewhere"? |
| 21:57 | <ljharb> | regex flags is an accessor, for example |
| 21:57 | <Bakkot> | I mean that the information they give you, or some of that information, is available by other means |
| 21:57 | <Bakkot> | regex flags, for example, also affect behavior |
| 21:57 | <ljharb> | right |
| 21:57 | <Bakkot> | so there is _underlying_ state which they reveal |
| 21:58 | <Bakkot> | so it makes sense for them to be accessors |
| 21:58 | <ljharb> | imo the list of errors is underlying state for AggregateError objects |
| 21:58 | <ljharb> | it's the only thing that differentiates it from the other error types |
| 21:58 | <Bakkot> | it is not underlying |
| 21:58 | <Bakkot> | there is no other way that information is reflected |
| 21:59 | <Bakkot> | that _is_ the state |
| 21:59 | <Bakkot> | compare, for example, the .name own property of functions |
| 21:59 | <ljharb> | sure. but having a name doesn't make it a function |
| 21:59 | <Bakkot> | ... what? |
| 21:59 | <ljharb> | you can delete the property and it stil |
| 21:59 | <ljharb> | it's still a function |
| 22:00 | <Bakkot> | ... ok? |
| 22:00 | <Bakkot> | what does that have to do with anything? |
| 22:00 | <ljharb> | so "errors" is the essence of an aggregate error instance |
| 22:00 | <ljharb> | otherwise it's just a normal error with a property on it |
| 22:00 | <Bakkot> | are we suddenly aristotelians? |
| 22:00 | <ljharb> | no idea what that means |
| 22:01 | <Bakkot> | I guess it's Plato not Aristotle really |
| 22:01 | <Bakkot> | https://en.wikipedia.org/wiki/Theory_of_forms |
| 22:01 | <Bakkot> | anyway my point is that it seems very strange to me to insist that things "have essences" distinct from... what they are |
| 22:02 | <Bakkot> | an aggregate error is a thing with errors, yes |
| 22:02 | <Bakkot> | that is why it has an errors property |
| 22:02 | <ljharb> | right |
| 22:02 | <Bakkot> | but that doesn't mean it needs to be an accessor |
| 22:02 | <ljharb> | but in JS, things are generally things because of slots (i'm sure there's counterexamples) |
| 22:02 | <ljharb> | a function is a function because of [[Call]]. `name` is incidental |
| 22:03 | <ljharb> | errors are weird in that there's no inherent difference between all the existing error types, and i don't want to add another weird error type |
| 22:03 | <Bakkot> | wait, you are the one who is trying to add another weird error type |
| 22:04 | <ljharb> | to me this makes it a normal instance instead of a weird one |
| 22:04 | <Bakkot> | you just said you were opposed to AggregateError being a normal error with a list of errors attached |
| 22:04 | <ljharb> | right |
| 22:04 | <ljharb> | because that's weird |
| 22:04 | <Bakkot> | what |
| 22:04 | <Bakkot> | objects have properties in javascript |
| 22:04 | <Bakkot> | that is the normal state of affairs |
| 22:04 | <Bakkot> | slots are not the normal state of affairs |
| 22:04 | <ljharb> | right but those properties are not their brand |
| 22:04 | <ljharb> | things are what they brand check to be |
| 22:05 | <ljharb> | otherwise they're just objects with properties that you're duck typing |
| 22:05 | <Bakkot> | I am not on board with the philosophy that brand checks are good, but leaving that aside for the sake of argument: OK, so that means you are introducing _a new brand check_, which is to say you are introducing _a new, distinct kind of object_ |
| 22:06 | <Bakkot> | as opposed to just having the one kind of error |
| 22:06 | <ljharb> | yes. Aggregate errors are a new distinct kind of object |
| 22:06 | <Bakkot> | not unless we choose to make them so |
| 22:06 | <Bakkot> | we do not need to make that choice |
| 22:06 | <Bakkot> | we did not make that choice for other error types |
| 22:07 | <Bakkot> | I don't think we should do so for this one |
| 22:07 | <ljharb> | i think we should have |
| 22:07 | <ljharb> | and tbh i don’t think that was an active choice, it was just legacy |
| 22:08 | <Bakkot> | I can call up my dad and ask I guess |
| 22:08 | <ljharb> | that would be very interesting history to know |
| 22:08 | <Bakkot> | but I am reasonably confident that it was not just legacy |
| 22:08 | <ljharb> | if there’s actually a philosophy behind it then that should inform this, and I’d love to know it |
| 22:09 | <Bakkot> | I'll ask next time I talk to him, I guess |
| 22:09 | <Bakkot> | but I don't think it's actually all that important |
| 22:09 | <Bakkot> | the language is what it is |
| 22:09 | <ljharb> | absent one, i consider it a mistake (accidental or intentional), and i don’t want to worsen it by adding yet another error type |
| 22:09 | <Bakkot> | you are the one adding another error type! |
| 22:09 | <Bakkot> | I am so confused by your claim that you are not adding another error type! |
| 22:10 | <Bakkot> | "things are what they brand check to be" - you |
| 22:10 | <ljharb> | lol, ok let me try again |
| 22:10 | <ljharb> | error types, unlike other types, lack proper differentiation between themselves |
| 22:10 | <ljharb> | i don’t want to add another error type that isn’t properly differentiated from the others |
| 22:10 | <Bakkot> | why |
| 22:11 | <Bakkot> | why not instead say that, consistent with the above, there is just one "type" of error from the brand check perspective |
| 22:11 | <Bakkot> | and that to add a new brand would be to split that type into two |
| 22:11 | <Bakkot> | for no reason |
| 22:11 | <ljharb> | i see that argument |
| 22:16 | <ljharb> | i mean, i don’t agree it’s for no reason. But i concede that it would result in two clouds of errors, one of improperly distinguished ones, and the other with aggregate error. And especially if we never add new error types, one might see that as a wart instead of as an improvement. |
| 22:21 | <Bakkot> | that is roughly my position, yes. actually mine is somewhat stronger: my position is that it is in general bad to make things brand-check distinguishable unless there is some reason to do so other than liking things to be brand-check distinguishable |
| 22:21 | <Bakkot> | entities should not be multiplied without necessity, and all that |
