| 00:20 | <rniwa> | Domenic: I don't understand your comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544 at all |
| 00:20 | <rniwa> | Domenic: import { myClass } from 'mymodule'; |
| 00:20 | <rniwa> | var a = new myClass; |
| 00:20 | <rniwa> | Domenic: wouldn't result in a ReferenceError of any sort |
| 00:22 | <caitp-> | my understanding is that module imports are resolved before evaluation starts |
| 00:22 | <caitp-> | too lazy to confirm |
| 00:23 | <caitp-> | tdz of some sort i'm sure, but still |
| 00:27 | <rniwa> | caitp-: Right. |
| 00:27 | <rniwa> | caitp-: the fact it blows up in the case of a circular dependency is an orthogonal issue |
| 00:27 | <caitp-> | iirc there's language to solve that, too |
| 00:28 | <caitp-> | at the very least direct circular imports are ignored |
| 00:30 | <caitp-> | oh, s/ignored/throws a syntax error |
| 00:32 | <rniwa> | caitp-: I think we did solve that issue by throwing ReferenceError |
| 00:32 | <caitp-> | yes, ResolveExport returns null, and in response all callers throw a SyntaxError |
| 00:33 | <caitp-> | so, maybe not quite as nice |
| 00:36 | <rniwa> | caitp-: well, circular dependency usually implies a programming error though |
| 00:36 | <rniwa> | so that might be okay |
| 00:36 | <rniwa> | although there are legitimate use cases... |
| 00:41 | <caitp-> | in any case it's not a reference error or type error to touch an import "before it's loaded", because you can't (with the exception of dynamic module imports) |
| 06:12 | <zcorpan> | TabAtkins: can't omit </p> there, as it happens |
| 07:04 | <zcorpan> | TabAtkins: help http://dev.w3.org/csswg/bikeshed/cssom-view/ |
| 07:06 | <zcorpan> | TabAtkins: also when i remove open() from Ignored Terms i get this: |
| 07:06 | <zcorpan> | WARNING: Multiple possible 'idl' refs for 'open()'. |
| 07:06 | <zcorpan> | Arbitrarily chose the one in html. |
| 07:06 | <zcorpan> | If this is wrong, insert one of the following lines into a <pre class=link-defaults> block: |
| 07:06 | <zcorpan> | spec:html; type:method; for:Window; text:open() |
| 07:06 | <zcorpan> | spec:html; type:method; for:Window; text:open() |
| 12:33 | <MikeSmith> | /win/win 2 |
| 12:57 | <ondras> | win-win! |
| 16:14 | <TabAtkins> | zcorpan: Specs that aren't Bikeshedded sometimes define things twice, and I don't know how to avoid that. That's why it was in Ignored Terms. ^_^ |
| 16:15 | <darobin> | mmmmm |
| 16:15 | <darobin> | maybe this should be in the pubrules validator |
| 16:15 | <darobin> | don't define thing twice |
| 16:16 | <darobin> | the tool could do a lot more linting |
| 16:17 | <TabAtkins> | darobin: That would be nice! In this case, though, it's HTML, which I don't think is really PubRules checked. ^_^ |
| 16:17 | TabAtkins | wonders if he should just make Bikeshed ignore it when it ends up with two identical definitions, and just silently choose one for you. |
| 16:17 | <darobin> | TabAtkins: well, if it's a part that is kept on the W3C side it gets pubrules checked every time it changes :) |
| 16:18 | <darobin> | and we could add support for linting WHATWG specs to specberus |
| 16:18 | <TabAtkins> | spec:html refers to WHATWG, yeah. |
| 16:19 | <TabAtkins> | zcorpan: I'll fix the stacktrace, though. |
| 16:30 | <annevk> | Apple's feedback reads pretty well to me |
| 16:30 | <annevk> | smaug____: you read it? |
| 16:33 | <smaug____> | annevk: well... |
| 16:34 | <smaug____> | it feels odd that you effectively say from outside the component where your child nodes should be distributed |
| 16:34 | <smaug____> | that hasn't been the idea with XBL and such |
| 16:35 | <smaug____> | but perhaps the slots + imperative API is enough |
| 16:35 | <annevk> | oh that bit, yeah, I'm not a 100% sold on slots yet, though I kind of like it |
| 16:36 | <annevk> | seems somewhat nice to have an opinionated public API contract |
| 16:42 | <Domenic> | It worries me that it means shadow DOM isn't useful for explaining <details> or <select> or similar. |
| 16:45 | <smaug____> | shadow DOM (or shadow + custom) isn't enough to explain various behaviors of native elements |
| 16:45 | <smaug____> | but the slots approach does seem to take us even farther(sp?) away |
| 16:47 | <smaug____> | long ago when there was xforms (yes yes, I know) addon for Firefox, XBL, which has roughly the same capabilities as shadow dom + custom, wasn't enough to implement the new elements. |
| 16:47 | <smaug____> | XTF + XBL was enough |
| 16:47 | <smaug____> | XBL was used mainly as a presentation layer, and XTF was the lower level thing |
| 16:48 | <smaug____> | but XTF was so low level, that only privileged scripts could use it to implement new stuff |
| 16:50 | <Domenic> | For sure, it isn't enough, it's part of the puzzle. Or at least it would be, if we didn't have this slots thing. |
| 18:47 | <hober> | MikeSmith dglazkov: dumb github question. How do I get write access to the w3c/webcomponents.wiki repo (i'm trying to add a wiki page) |
| 18:47 | <MikeSmith> | hober: I have to add you |
| 18:48 | <hober> | MikeSmith dglazkov: normally i'd send a pull request but github doesn't do pull requests for gh wikis |
| 18:48 | <MikeSmith> | because of asshatted github ACLs setup |
| 18:48 | <MikeSmith> | yeah |
| 18:48 | <hober> | MikeSmith: ahh ok |
| 18:48 | <hober> | MikeSmith: thanks |
| 18:49 | <trevnorris> | Domenic: would there be some es6 class magic that would allow an inherited static method change a property on the inherited class? probably doesn't make sense. i'll write up some code. |
| 18:50 | <MikeSmith> | hober: you should be good to go now |
| 18:50 | <hober> | awesome, it worked. thanks! |
| 18:51 | <othermaciej> | MikeSmith: can I be added to so I can edit what hober just uploaded? |
| 18:51 | <othermaciej> | MikeSmith: I have a github account as “othermaciej” |
| 18:54 | <trevnorris> | Domenic: here's using both 5 and 6. https://gist.github.com/trevnorris/e3144f66dfa0aac6ff27 |
| 18:57 | <MikeSmith> | othermaciej: hai, just added you |
| 18:58 | <othermaciej> | MikeSmith: thanks |
| 19:01 | <trevnorris> | Domenic: actually, can es6 classes have static members that aren't methods? |
| 19:16 | <Domenic> | trevnorris: sure, MyClass.x = "whatever" (or use static get/static set for accessors) |
| 19:17 | <trevnorris> | Domenic: though that really gimps "use strong" for v8. |
| 19:17 | <Domenic> | Yes well if you wanna program in JS program in JS if you wanna program in a V8 dialect program in that |
| 19:17 | <Domenic> | trevnorris: the two things in your gist look equivalent |
| 19:18 | <trevnorris> | Domenic: I just updated the es6 example with a more full implementation to show the required code duplication. |
| 19:18 | <Domenic> | Note that `this` inside static methods is the class itself |
| 19:18 | <trevnorris> | Domenic: even if it's inherited? |
| 19:19 | <trevnorris> | FREAK YES! |
| 19:19 | <Domenic> | None of the stuff you just added to that gist is necessary |
| 19:20 | <trevnorris> | awesome. so I can use this._onreadable inside the static method and the inheritance will work. |
| 19:20 | <Domenic> | Yep yep. ES6 classes do class-side inheritance |
| 19:20 | <trevnorris> | okay. i'm actually a little excited for es6 class syntax (still hate the class keyword since it's technically prototype, but whatever) |
| 19:22 | <trevnorris> | sweet, sweet. extends even makes sure to extend the static stuff after the fact. alright. this is legitimately good sugar. :) |
| 19:23 | <Domenic> | In ES5 terms, Derived.__proto__ = Base in addition to Derived.prototype.__proto__ = Base.prototype |
| 19:23 | <Domenic> | Haha yay :) |
| 19:29 | <gsnedders> | jgraham: do you have thoughts on how Reviewable compares with Critic? |
| 19:29 | <gsnedders> | Domenic: __proto__ isn't an ES5 term! *hides* |
| 19:32 | <trevnorris> | Domenic: hm. was getting ahead of myself and didn't think through the implementation impact. e.g. https://gist.github.com/trevnorris/e3144f66dfa0aac6ff27#file-inheritence-stuff-es6-js |
| 19:33 | <trevnorris> | Domenic: how do I get the _onreadable value from the specific class calling the constructor in Readable? |
| 19:34 | <trevnorris> | because it is changing the value on the inherited class properly, but not sure how to get it from the Readable constructor(). |
| 19:53 | <trevnorris> | Domenic: nm. got it figured out. didn't know you could reference this.constructor. |
| 21:10 | <jgraham> | gsnedders: They managed to make the UI even more confusing |
| 21:11 | <gsnedders> | jgraham: impressive. |
| 21:12 | <gsnedders> | jgraham: sounds like it integrates better with GH, though |
| 21:31 | <MikeSmith> | does anybody ever try to run blame on the HTML spec |
| 21:31 | <MikeSmith> | nm |
| 21:31 | <MikeSmith> | was just taking a lot longer than I remembered it taking |
| 21:51 | <trevnorris> | Domenic: is there a spec somewhere for "new.target" within a class constructor? |
| 22:04 | <caitp> | trevnorris, what do you mean? |
| 22:05 | <trevnorris> | caitp: posted something on the "use strong" mailing list and someone told me that you can't use "this.constructor" in a constructor() callback. instead should use "new.target" |
| 22:05 | <trevnorris> | caitp: never heard of it before. |
| 22:05 | <caitp> | it's a new thing |
| 22:05 | <caitp> | as of like january, iirc |
| 22:05 | <trevnorris> | ah, okay. is there a spec out for it, or has it just been discussed? |
| 22:05 | <caitp> | if "new.target" is undefined, it means that the function was not called with `new` |
| 22:06 | <caitp> | yeah, it's all in the ES spec --- search for [[NewTarget]] |
| 22:06 | <trevnorris> | thanks. |
| 22:06 | <caitp> | if it's not undefined, it's the target constructor (eg, the one which was the operand of `new`) |
| 22:13 | <gsnedders> | MikeSmith: yes |
| 22:39 | <jgraham> | gsnedders: Yes, the github integration is better in the sense that rebases are more seamless and it seems to not randomly fail to sync occasionally |
| 22:39 | <jsbell> | uh, so idlharness requires ES6 arrow functions now? |
| 22:39 | <jgraham> | jsbell: That's a bug, fixes welcome |
| 22:39 | <jgraham> | I thought someone already fixed it but apparently not |
| 22:40 | <jgraham> | (people have been using them in Mozilla code for years, so it's easy to forget they don't work everywhere yet) |
| 22:45 | <jsbell> | jgraham: https://critic.hoppipolla.co.uk/r/4777 |
| 22:45 | <jsbell> | "works on my machine" |
| 22:49 | <jgraham> | jsbell: r+ and merged |
| 22:51 | <jsbell> | jgraham: yay |
| 22:51 | <jgraham> | jsbell: Thanks for the fix and sorry for the inconvenience |
| 22:54 | <jsbell> | np; now to figure out if I should add allow_uncaught_exception sprinkles to some tests... |
| 23:48 | <TabAtkins> | zcorpan: Okay, stacktrace fixed. That one was tricky! |