| 06:53 | <annevk> | Domenic: platform objects by default should not require a proxy |
| 06:54 | <annevk> | TabAtkins: likely Hixie |
| 07:37 | <tobie> | annevk: re-open dictionary, why are we not picking the same processing model for open dictionary than for existing dictionaries? |
| 07:37 | <annevk> | tobie: not sure, would make sense if we did |
| 07:38 | <annevk> | tobie: maybe currently impls don't, but does not seem like a breaking change |
| 07:39 | <tobie> | annevk: not sure what you mean. Open dic isn't implemented anywhere, is it? |
| 07:47 | <annevk> | tobie: Fx has MozMap |
| 07:48 | <annevk> | tobie: not sure what others do for Headers |
| 07:48 | <tobie> | annevk: IS the only use case of MozMap Headers? |
| 07:48 | <annevk> | tobie: I think there is some other internal usage |
| 07:49 | <tobie> | annevk: I see. |
| 07:50 | <tobie> | annevk: if we want open-dictionaries and dictionaries to be variants of the same "type" and want conversion with half-open dictionaries in the not too distant future, then I believe we want the same processing model for both |
| 07:52 | <tobie> | annevk: if the only reason for a model change is to map (pardon the pun) MozMap, then it feels like that shouldn't be a huge compat issue |
| 07:53 | <tobie> | annevk: if there are other reasons I'm not aware of (e.g. perf?) then the story is different. |
| 07:53 | <annevk> | tobie: note that I'm not sure what the reason for the diff is |
| 07:53 | <annevk> | tobie: jyasskin might know |
| 07:54 | <annevk> | tobie: but seems like something we should get clarified |
| 07:54 | <tobie> | annevk: yup--commenting on the issue |
| 08:05 | <annevk> | ta |
| 08:30 | <kochi> | zcorpan: as I chatted with rniwa about alternative stylesheet handling in shadow dom, I read again https://github.com/w3c/webcomponents/issues/391 and found https://www.w3.org/Bugs/Public/show_bug.cgi?id=29349 is still open. Does it make sense to move the bug to csswg-drafts issue and work on it? |
| 08:31 | <annevk> | kochi: submitting a PR to close that bug is fine too |
| 08:32 | <annevk> | kochi: that's what we do for legacy bugs for most WHATWG drafts |
| 08:34 | <kochi> | annevk: okay, no need to migrate the issue to github. |
| 08:35 | <annevk> | kochi: yeah, perhaps only if it needs a lot more discussion that's worth it, since it's easier for folks to use GitHub |
| 08:35 | <annevk> | kochi: but moving all the issues from one place to another creates a lot of noise unfortunately |
| 08:36 | <kochi> | annevk: i see, probably the discussion is all set for the issue, what is left is to update cssom spec accordingly. |
| 09:01 | <annevk> | When is something a trusted event? |
| 09:01 | <annevk> | If the ECMAScript stack is empty? |
| 09:05 | <Ms2ger> | If the UA dispatches it, generally |
| 09:06 | <annevk> | Ms2ger: but click() is dispatched by the UA too |
| 09:06 | <Ms2ger> | "generally" :) |
| 09:07 | <annevk> | Yeah, so when would ECMAScript stack being empty not be a good condition? |
| 09:07 | <Ms2ger> | postMessage? I guess that might run off a task |
| 09:08 | <ondras> | annevk: click() dispatches synchronously? |
| 09:08 | <annevk> | ondras: yes |
| 09:09 | <ondras> | ah |
| 09:09 | <annevk> | Ms2ger: it does, but I guess it's an exception therefore, since isTrusted is false |
| 09:10 | <Ms2ger> | Oh, it is? |
| 09:10 | <Ms2ger> | Maybe smaug has more of this paged in |
| 09:11 | <annevk> | I think he might be the only one |
| 11:04 | <Ms2ger> | annevk, what's this "trailer" stuff in fetch? |
| 11:05 | <annevk> | Ms2ger: feature from HTTP folks wanted to see exposed |
| 11:05 | <annevk> | Ms2ger: some subset of implementers of most browsers seemed okay with it, but nobody started implementing afaik |
| 11:05 | <Ms2ger> | I see |
| 11:12 | <annevk> | smaug: per your comment about postMessage() needing to dispatch trusted events, does that mean it's basically about the JavaScript stack being empty? |
| 11:12 | <annevk> | smaug: also, how does that make click() an exception? Since in that case the JavaScript stack wouldn't be empty (and the event is untrusted, or should that be trusted too?) |
| 11:13 | <smaug> | annevk: well, mutation events are trusted |
| 11:13 | <annevk> | smaug: I see |
| 11:14 | <annevk> | smaug: that is a little weird |
| 11:14 | <annevk> | smaug: but I guess it depends on what the principles all |
| 11:14 | <annevk> | are* |
| 11:16 | <smaug> | all the UA dispatched events are trusted, and click() is a special case since it is just a shorthand to: element.dispatchEvent(new MouseEvent("click")); |
| 11:17 | <smaug> | something like that |
| 11:17 | <annevk> | I think click() is a little more complicated than that, but okay |
| 11:17 | <annevk> | I'm going to open an issue against whatwg/dom to get this settled throughout specifications |
| 11:19 | <smaug> | click() does check/set/clear the "is handling click event flag", but other than that, it just dispatches the event |
| 12:36 | <tobie> | why is a callback function not distinguishable from a dictionary? |
| 12:37 | <tobie> | …or from an object? |
| 12:41 | <Ms2ger> | A dictionary is just an object |
| 12:43 | <tobie> | write, but a callback function is a function, right? |
| 12:44 | <Ms2ger> | And a function is little more than an object :) |
| 12:45 | <tobie> | well, it's precisely "little" more (it is callable). |
| 12:46 | <Ms2ger> | Sure |
| 12:47 | <Ms2ger> | Dunno if the distinguishability check ever looked at IsCallable |
| 12:47 | <Domenic> | tobie: annevk: how could you possibly have the same processing model for them? they're completely different. |
| 12:47 | <Domenic> | dictionaries have a set of known keys, open dictionaries need to enumerate all keys. |
| 12:47 | <annevk> | Domenic: it's about considering just own props vs also protoprops |
| 12:48 | <tobie> | Domenic: that ^ |
| 12:48 | <annevk> | Domenic: that's one of the differences bz highlighted |
| 12:48 | <Domenic> | OK. |
| 12:48 | <annevk> | Domenic: tobie: I'm typing a reply to the issue atm |
| 12:48 | <Domenic> | I think a JS implementation would probably do Object.keys() |
| 12:48 | <Domenic> | in ES we've made a few decisions based on own-enumerable as the "copying protocol" |
| 12:49 | <Domenic> | E.g. Object.assign or the upcoming { ...objectSpread } |
| 12:49 | <annevk> | Domenic: so that would be different from dictionaries in IDL then |
| 12:49 | <Domenic> | Right, because they're very different models... |
| 12:49 | <annevk> | Domenic: and wouldn't cater for flattening DOM objects |
| 12:49 | <Domenic> | For dictionaries you just do `obj.prop` |
| 12:50 | <Domenic> | For open-ended things you enumerate the props |
| 12:50 | <Domenic> | At TC39 we discussed this as "classes vs. records" |
| 12:50 | <Domenic> | classes have prototype chains, records do not |
| 12:50 | <Domenic> | Property access needs to work for both so it uses the prototype chain |
| 12:50 | <annevk> | Domenic: you should totally weigh in with this stuff I thikn |
| 12:50 | <Domenic> | but things like Object.assign, Object.keys, { ...objectSpread } do not |
| 12:50 | <Domenic> | Yeah |
| 12:50 | <Domenic> | Just woke up ^_^ |
| 12:50 | <annevk> | Domenic: esp ...objectSpread, decisions made in TC39/JavaScript so far, etc. |
| 12:51 | <annevk> | Domenic: fair |
| 12:52 | <tobie> | But for devs, imagine how crazy it'll be if half-open dictionaries allow properties on the proto if those are defined by a dictionary member but on the object only if they're not. |
| 12:53 | <annevk> | tobie: yeah, web animations seems to have that mismatch at the moment, I agree that's weird |
| 12:53 | <annevk> | Domenic: ^ |
| 12:53 | <Domenic> | I think jyasskin's intuition is right and that the difference only matters in obfuscated JS contests |
| 12:54 | <Domenic> | For the common case of foo({ bar: x, baz: y }) it does not matter |
| 12:57 | <tobie> | Domenic: I can totally imagine creating a base class with shared options, which would work well for those properties defined with member dictionaries but break unexpectedly the minute I add an unspecified property |
| 12:57 | <Domenic> | tobie: that's the reason why we distinguish between classes and records. |
| 12:58 | <Domenic> | You can't in general use classes for options |
| 12:58 | <Domenic> | It'll break many parts of the language (Object.keys, Object.assign, object spread) |
| 12:58 | <annevk> | Rereading that thread I notice that I indeed missed jyasskin already pointed out that difference (though no motivation, so asking still seems reasonable) |
| 12:58 | <annevk> | But more importantly, bz dropped a StructuredClone bug report in there |
| 12:59 | <Domenic> | I really thought we went through StructuredClone with aklein and got everything right, last time :-S |
| 12:59 | <tobie> | Domenic: can't we move away dictionaries from fetching stuff on the prototypes, then? OR would that break web-compat? |
| 13:00 | <Domenic> | tobie: I don't think that's desirable, since it would mean dictionaries do something more exotic than `foo.bar`. The problem here is with the JS language which hasn't reified the difference between records and class instances. |
| 13:01 | <annevk> | Domenic: you mean apart from the serializing/deserializing mess? -_- |
| 13:02 | <Domenic> | heh |
| 13:02 | <annevk> | tobie: we can't move away from that, e.g., new Request(url, oldRequest) is a thing now |
| 13:03 | <tobie> | but oldRequest isn't specified as a dictionary there, is it? |
| 13:03 | <tobie> | Domenic: I understand your perspective and I agree that it makes sense from it, but that seems like favoring technical purity over dev experience. |
| 13:03 | <annevk> | tobie: it is, the class just happens to match the record layout |
| 13:04 | <annevk> | (to use Domenic's terms) |
| 13:04 | tobie | 's head explodes |
| 13:05 | <tobie> | maybe half-open dictionaries are a dreadful idea. |
| 13:06 | <annevk> | Domenic: seems bz missed that StructuredClone fails on proxies, pfew |
| 13:07 | <annevk> | tobie: well, I think web animation shipped |
| 13:08 | <Domenic> | I don't think the dev experience will be changed either way |
| 13:10 | <tobie> | well, a long time ago I would have argued these weird corner cases are the reasons people hate Web development… |
| 13:10 | <tobie> | nowadays we have this: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f |
| 13:11 | <annevk> | tobie: https://twitter.com/steveklabnik/status/783321843793010688 |
| 13:12 | <annevk> | Corner cases not working across browsers is more problematic I think |
| 13:12 | <annevk> | And it's not clear we have good solutions here |
| 13:13 | <gsnedders> | annevk: imo that's missing the problem; the big problem with JS-land is we have multiple different package managers which work in different ways, many of which are really designed for server-side JS but we use them for client-side stuff anyway. |
| 13:14 | <gsnedders> | also the JS community is so full of fads that come and go so fast; there's so little stability in what's considered good |
| 13:15 | <tobie> | annevk: whereby "here" you're referring to the Web in general or half-open dictionaries? |
| 13:15 | <tobie> | annevk: sort of lost context |
| 13:15 | <annevk> | tobie: heh, half-open dicts |
| 13:16 | <annevk> | tobie: though I guess same for web in general? |
| 13:17 | <tobie> | annevk: yeah, the latter goes without saying, I could have framed my question more precisely. :) |
| 13:19 | <gsnedders> | speaking of web dev today, I find it kinda sad I have little motivation to write in JS or CSS, rather than languages that compile to them |
| 13:39 | <Domenic> | there's only one package manager for JS these days, and it's designed for both ecosystems... |
| 13:41 | <nox> | gsnedders: Which languages btw? |
| 13:42 | <gsnedders> | Domenic: depends whether you consider npm and bower the same, which they probably aren't |
| 13:45 | <gsnedders> | nox: TypeScript and SCSS mostly |
| 13:45 | <nox> | gsnedders: Nice. I fancy the TS engineering even though I don't use JS nor anything that targets it. |
| 13:46 | <caitp> | my experience with TypeScript is that it didn't really solve any real problems and just gave me a bunch of extra crap to do to get anything done, while simultaneously breaking liveedit and debugging |
| 13:47 | <caitp> | I'm not sure why anyone feels that's a good thing, but I guess opinions and experiences vary :x |
| 13:49 | <annevk> | tobie: jyasskin : Domenic: so maybe the solution is to have record<ByteString, ByteString> and for half-open we could do (record<> or DictionaryName) |
| 13:49 | <Domenic> | bower doesn't really exist anymore |
| 13:49 | <Domenic> | I guess maybe polymer pretends it does |
| 13:50 | <Domenic> | annevk: the union type doesn't work because halfopen wants to grab several fields with type conversions/required/etc. and then enumerate the rest |
| 13:50 | <annevk> | Domenic: yeah, I guess that would end up being a little confusing |
| 13:53 | <gsnedders> | Domenic: as for why I'll argue npm is really designed for server-side stuff: it doesn't really handle non-JS assets in any decent way. bower is still relied on by a fair few things, for better or for worse. |
| 13:54 | <tobie> | well, given Domenic's input on the issue itself, it seems this is essentially a problem with ES itself. |
| 13:55 | <gsnedders> | caitp: I definitely have experiences of TS finding bugs that would've been missed otherwise in all likelihood. And given plenty of things rely on build-steps anyway, liveedit is pretty much already dead for better or for worse. |
| 13:55 | <Domenic> | gsnedders: I guess this is just ignoring the reality of JS dev as it exists today, which is that people use npm for client side including all non-JS assets with no issues. |
| 13:55 | <gsnedders> | Domenic: oh, I'm not saying people *don't* use it for it |
| 13:56 | <gsnedders> | Domenic: I'm just saying that it doesn't address those needs well |
| 13:56 | <tobie> | gsnedders: it'll eventually do so. it's on their roadmap |
| 13:56 | <caitp> | I wouldn't be so offended by the "extra crap it forces you to do" if optional types were an engine feature, and I believe Mozilla is interested in exploring that possibility? At least, that's what "typed objects" sounds like |
| 13:56 | <gsnedders> | tobie: I don't doubt it; it's an obvious thing to fix for the front-end side of things. |
| 13:57 | <gsnedders> | caitp: I think there's generally an interest in adding gradual typing to ES, but I think there's some hesitancy about it given ES4's gradual typing was certainly a significant downfall |
| 13:58 | <annevk> | caitp: aren't typed objects just ArrayBuffer objects with fancy access? |
| 13:59 | <caitp> | I have no idea, I'm not familiar with their plan for it |
| 13:59 | <gsnedders> | caitp: and, uh, what annevk just said. |
| 13:59 | <caitp> | but it sounds similar to v8's experiments |
| 13:59 | <caitp> | by title alone |
| 13:59 | <gsnedders> | annevk: they aren't necessarily array-like, though |
| 14:00 | <annevk> | gsnedders: what I remember sounded like structs, which I'm also not super familiar with, mind you |
| 14:01 | gsnedders | doesn't know quite what the current proposal is, having been out of the TC-39 world for a long while now |
| 14:02 | <caitp> | are you thinking like, the "value types" thing? |
| 14:02 | <tobie> | annevk: wrt new Request(url, oldRequest), couldn't you redefine the constructor's second argument as (dictionary or Request) or are there weird WebIDL rules that prevent you from doing so? |
| 14:03 | <annevk> | tobie: it's possible, though it would be subtly different of course and doesn't address other places that take dictionaries |
| 14:04 | <tobie> | annevk: agreed. |
| 14:04 | <annevk> | tobie: I guess we need to decide how important half-open is |
| 14:04 | <annevk> | tobie: otherwise record<> seems like the way to go for now |
| 14:05 | <annevk> | tobie: we could separately discuss if redoing dictionary is worth it, but I suspect not, given that dict.member is kinda intuitive |
| 14:06 | <tobie> | annevk: agree. well, not reaching into the proto chain could be explained by the fact we're passing by value. |
| 14:06 | <tobie> | annevk: i.e. there's some form of cloning going on (however that's described in the spec) |
| 14:28 | <annevk> | beverloo: I can try land that now |
| 14:29 | <beverloo> | annevk, thanks! we're looking at one or two more things and then we're going to pause for a while, at least until you or Microsoft catch up |
| 14:29 | <annevk> | beverloo: actually, if John could enable contributions from others to that branch I can fix it up and land it |
| 14:29 | <annevk> | beverloo: he should have a little checkbox in the sidebar |
| 14:31 | <beverloo> | annevk, done |
| 14:45 | <annevk> | beverloo: same |
| 14:45 | <annevk> | beverloo: please say "thanks John" |
| 14:45 | <beverloo> | done :) Thank you! |
| 15:02 | <TabAtkins> | annevk: Yeah, "value types" are fancy wrappers around array buffers basically, + some niceties about comparison and possibly operator overloading. |
| 15:03 | TabAtkins | still really wants someone to champion them so we can use them in CSS. |
| 15:04 | <Domenic> | value types are different from typed objects |
| 15:04 | <Domenic> | i think it's typed objects that are wrappers around array buffers |
| 15:05 | <Domenic> | Hmm I guess it all fits together per latest thinking https://github.com/nikomatsakis/typed-objects-explainer |
| 15:05 | <TabAtkins> | I was under the impression that value types were still limited in what they could contain to basically be array buffers. |
| 15:06 | <TabAtkins> | Yeah, otherwise you don't get value equality. |
| 15:06 | <caitp> | "How It Feels to Learn Javascript in 2017" is going to be great with this stuff |
| 15:07 | <Domenic> | I liked https://twitter.com/jdalton/status/783348903940718593 on that subject |
| 15:08 | <jgraham> | I think that tweet misses the point |
| 15:09 | <TabAtkins> | I disagree with all the disagreement to that article. JS really is in a confusing state right now, and has been for a few years. I don't think it's just a normal amoutn of complexity, compared to other languages. |
| 15:09 | <caitp> | it is a mess, definitely |
| 15:09 | <jgraham> | The criticism of js is that there's a lot of accidential complexity that people deeply embedded in the community don't notice because they learnt each new thing incrementally |
| 15:09 | <JakeA> | TabAtkins: In Bikeshed, if I have "Let response be the result of fetching request" and I wanted "fetching" to link to https://fetch.spec.whatwg.org/#concept-fetch, what's the best way to do that? |
| 15:10 | <jgraham> | Whereas for someone coming in it's a wall of WTF |
| 15:10 | <TabAtkins> | JakeA: That should just work? |
| 15:10 | <TabAtkins> | jgraham: Right. And it hasn't been integrated or polished yet so that it's approachable for newcomers. |
| 15:10 | <TabAtkins> | JakeA: <a>fetching</a> should work, that is. |
| 15:11 | <jgraham> | (and ftr I don't think it's a "js-the-language" criticism so much as a "js-the-ecosystem" criticism) |
| 15:11 | <JakeA> | TabAtkins: Bikeshed somehow understands that "<a>fetching</a>" should point to https://fetch.spec.whatwg.org/#concept-fetch? I thought I'd have to add "text: fetching; url: concept-fetch" to the anchors |
| 15:12 | <caitp> | I think you could write our own article about js-the-language, tbh, but yes |
| 15:12 | <TabAtkins> | JakeA: Oh gosh no. Anchor block is just for specs that aren't in the Bikeshed db; Fetch definitely is. |
| 15:13 | <caitp> | the ecosystem is scary, but people feel they have to use that ecosystem instead of just js-the-language, so the two are sort of undistinguishable |
| 15:13 | <JakeA> | TabAtkins: ahh, so is "fetching" linked to "fetch" somewhere? |
| 15:13 | <JakeA> | Or does it perform magic around <something>ing |
| 15:13 | <TabAtkins> | Bikeshed's got some auto-Englishing around "dfn" type autolinks. |
| 15:13 | <jgraham> | caitp: I think I agree with that, but my point is that I don't see what language changes you could make to solve the problems |
| 15:14 | <TabAtkins> | Most of the standard English word variants will work. |
| 15:14 | <JakeA> | ahh ok. Cheers! |
| 15:14 | <caitp> | jgraham: they'll add new paragraphs about "use babelXXX preset 2019 to use value types, but note that these are not the same as the support for typed objects by TypeFlowScript v. 29.0.1" |
| 15:16 | <Domenic> | http://cube-drone.com/comics/c/how-it-feels-to-learn-javascript-in-2016 |
| 15:17 | <caitp> | compare it to learning rust or objc |
| 15:18 | <caitp> | anyways, time to get back to doing productive things |
| 15:19 | <jgraham> | I mean the fact that js seems to get far more feedback of this kind than any other language could mean something. Or you could ignore it and imply that everyone who isn't totally happy with the ecosystem is a caveman, I guess |
| 15:21 | <TabAtkins> | I imagine that, for example, Lisp had the same complaints about it before they went and standardized an enormous stdlib. Lots of different OO systems floated around for a while, for instance. |
| 15:21 | <Domenic> | jgraham: I think JS gets far more of this feedback because it is used far more. |
| 15:22 | <jyasskin> | Domenic: how crazy would it be to have open dictionaries iterate the prototype chain? The spec language is more complicated, but it looks doable. |
| 15:22 | <Domenic> | jyasskin: not _crazy_, but I tried to argue this morning for why I think it is a bad idea. |
| 15:23 | <jyasskin> | I haven't read the issue yet; I'll go do that. |
| 15:30 | <jgraham> | Domenic: That would imply people are ~equally frustrated by ecosystem problems when they try to learn Java, C#, C, Python and PHP (based on various programming language popularity metrics I can find, which are of course not of great reliability) |
| 15:30 | <Domenic> | jgraham: that's been my experience, especially in Java and PHP. |
| 15:30 | <jgraham> | I'm pretty sure it's not true of Python |
| 15:31 | <jgraham> | So if your claim is "js is no worse to use than Java or PHP", I guess that might be true |
| 15:31 | <jgraham> | But it's a pretty low standard |
| 15:32 | <Domenic> | Well, the metrics I have seen indicate it outstrips those (especially Python) by a lot |
| 15:32 | <Domenic> | I don't think this discussion is terribly productive though, so we can just agree to disagree and move on. |
| 15:32 | <jgraham> | Sure, all I have are unreliable programming language ranking websites |
| 15:32 | <jgraham> | Sure |
| 16:02 | <JakeA> | TabAtkins: How do I solve "Multiple possible 'dfn'"? I guess I'm looking for an attribute or something where I can remove the ambiguity |
| 16:05 | <TabAtkins> | JakeA: The error message should tell you how to solve that. |
| 16:05 | <JakeA> | TabAtkins: Multiple possible 'dfn' local refs for 'type'. Arbitrarily chose the one with type 'dfn' and for 'service worker'. |
| 16:05 | <JakeA> | Doesn't seem so |
| 16:06 | <TabAtkins> | Oh, multiple locals. |
| 16:06 | <JakeA> | I want it to be https://fetch.spec.whatwg.org/#concept-response-type |
| 17:28 | <smaug> | Domenic: you should know, what does promise.then(another_promise) do? |
| 17:29 | <Domenic> | Smaug: nothing, it's just an error |
| 17:30 | <smaug> | aha |
| 17:30 | smaug | was just reading some code |
| 17:31 | <smaug> | Domenic: hmm, so promise.then(another_promise).then(function { console.log("foo")}); won't print foo? |
| 17:31 | smaug | tests |
| 17:33 | <Domenic> | I think it will just ignore the first then |
| 17:33 | <Domenic> | It's equivalent to passing undefinef |
| 17:34 | <smaug> | aha |
| 17:35 | <smaug> | confusing |
| 17:35 | smaug | would expect then() to throw in this case |
| 17:35 | <smaug> | but ok, thanks |
| 18:15 | <TabAtkins> | Domenic: I'd also expect it to throw. Is this "like undefined" behavior due to the thenable-coercion we ended up speccing? |
| 18:19 | <caitp> | > Domenic: hmm, so promise.then(another_promise).then(function { console.log("foo")}); won't print foo? << it should throw, argument to then() must be callable |
| 18:37 | <Domenic> | TabAtkins: no, unrelated. |
| 18:37 | <Domenic> | caitp: no, if the argument to .then is not callable it's ignored. |
| 18:37 | <Domenic> | At the time the only precedent was JSON.stringify/parse which ignored non-callables. |
| 18:37 | <caitp> | ah, you're right |
| 18:40 | <caitp> | I saw the "If IsCallable(onFulfilled) is False, then..." and assumed the worst :p |
| 18:47 | <jgraham> | FWIW I once spent some considerable time tracking down a bug due to promise1.then(promise2) rather than promise1.then(()=>promise2) |
| 18:48 | <jgraham> | (it was less obvious than that in real life ofc because the argument to .then was a function call |
| 18:48 | <jgraham> | ) |
| 18:48 | <TabAtkins> | Yeah, I wouldn't be surprised if it's not changeable now, but my experience with the platform would lead me to believe that it would throw, as that's the usual WebIDL behavior when you pass something unsuitable. |
| 18:48 | <jgraham> | Yeah, not waying we can change it |
| 18:49 | <jgraham> | Just that it's a design choice that caused a difficult-to-diagnose bug |
| 18:49 | <jgraham> | *saying |
| 18:49 | <Domenic> | IMO browser consoles should warn on it |
| 18:56 | <tobie> | A dead horse at this point, but still like Dion's perspective on the topic: https://medium.com/ben-and-dion/i-want-to-go-back-to-the-1950s-of-web-development-fa69d7fe357a |
| 18:56 | <caitp> | don't you think that would just incur performance hits that would lead people to just use Bluebird instead? |
| 18:57 | <caitp> | I mean, they already use BB instead of native promises because of the performance anyways, but... |
| 18:59 | <tobie> | Why does the number of nullable member types of a union type must be 0 or 1? (http://heycam.github.io/webidl/#dfn-number-of-nullable-member-types) |
| 18:59 | <jyasskin> | JakeA: Did you ever get an answer for your multiple-dfn error? I think you want `<a for="response">type</a>`. |
| 19:04 | <gsnedders> | hi |
| 19:04 | <TabAtkins> | Oh shoot yeah, I didn't answer Jake. Yeah, the `for="whatever"` thing is what you want - just match whatever the <dfn> you want uses. (Or if the one you want doesn't have a `for` attribute, use `for=/` on the link.) |
| 19:05 | <TabAtkins> | tobie: Because otherwise you can't tell, when you recieve a null, which nullable type it was meant for. This is important if you change behavior based on the type you receive. |
| 19:13 | <tobie> | TabAtkins: why then do we have an algorithm to count the number of nullable types of a union? http://heycam.github.io/webidl/#dfn-number-of-nullable-member-types |
| 19:14 | <TabAtkins> | tobie: For the purpose of restricting you to 0 or 1. |
| 19:14 | <tobie> | TabAtkins: :D |
| 19:14 | <TabAtkins> | I'm not being sarcastic - follow the uses of the definitions. ^_^ |
| 19:15 | <tobie> | TabAtkins: I know. That's what's funny, actually. |
| 19:17 | <tobie> | TabAtkins: this whole sections seems a lot simpler in practice than how it's specified. |
| 19:17 | <TabAtkins> | tobie: Probably! |
| 19:19 | <tobie> | TabAtkins: Thanks for the explanation. |
| 19:27 | <Domenic> | tobie: so you know which branch of the union null should go to, probably |
| 19:27 | <Domenic> | oh tab already answered |
| 19:27 | <tobie> | yeah--thanks |
| 19:33 | <JakeA> | jyasskin: cheers! Will give that a go |
| 19:42 | <jyasskin> | tobie: I think there's a lot in WebIDL that we can simplify. |
| 19:42 | <tobie> | Oh, so union types are not associative because of how null types work. `(DOMString? or Node)` is *not* the same as `(DOMString or Node)?` |
| 19:44 | <tobie> | Hence (Foo or (DOMString or Node)?) != (Foo or DOMString or Node)? |
| 19:45 | <tobie> | jyasskin: I hope you're right |
| 19:47 | <jyasskin> | Yes, that sounds right. You get extra "which type" information as you push the ? down. I hope nobody's taking advantage of that. |
| 19:51 | <tobie> | jyasskin: well if nobody is, the whole thing can be simplified to making union types associative and making the quality of being nullable bubble. |
| 19:51 | <tobie> | *bubble upwards. |
| 19:52 | <jyasskin> | That would be awesome. We'd probably have to lead with a Blink/Firefox patch doing it, to see what breaks. |
| 19:53 | <tobie> | jyasskin: coming mostly from JS, the whole idea of tying null to a type is sort of forain to me, so I find it hard to picture what this could break, here. |
| 19:58 | <jyasskin> | Imagine that a spec has (DOMString? or Node), and then the text says "if a DOMString was passed, do X; otherwise for a Node do Y". By bubbling null, we force the spec to change to treat null explicitly. |
| 20:00 | <jyasskin> | We could try to make "DOMString?" an alias of (DOMString or Null), but then we get the restriction that (DOMString? or Node?) is banned right back. |
| 20:06 | <tobie> | Well, it's banned for precisely the same reason, right? Not to have to treat null explicitly. |
| 20:08 | <tobie> | I'm curious though as to real examples of APIs allowing null but not handling it explicitly. |
| 20:11 | <jyasskin> | Me too. I don't have any, but my guess is that because it's possible, it's been done. |
| 20:12 | <jyasskin> | Making the change in a browser is probably the best way to find examples. |
| 20:15 | <tobie> | Yup and running the output through CI. |