| 00:09 | <JonathanNeal> | Is there a Fetch test suite? https://fetch.spec.whatwg.org/ |
| 00:31 | <MikeSmith> | JonathanNeal: none that I know of |
| 00:32 | <JonathanNeal> | Is the fetch API fairly simple? Is it a Promise-ified XMLHttpRequest? |
| 00:33 | <MikeSmith> | yeah that would be fair way to describe it I guess |
| 00:35 | <JonathanNeal> | Thanks, MikeSmith. Sounds good. |
| 00:36 | <MikeSmith> | JonathanNeal: there's a polyfill at https://github.com/github/fetch in case you've not found it on your own yet |
| 00:37 | <MikeSmith> | that does have a few tests |
| 00:38 | <MikeSmith> | and I guess you realize this but there's a lot more to the Fetch spec than just the API that's exposed |
| 00:39 | <JonathanNeal> | Yes, I’m seeing that as I look through the Headers and CORS sections. |
| 00:40 | <zewt> | dear firefox, #1 thing that will make me turn off auto-updates entirely: having a dialog with "update" and "later" buttons, but no "stop nagging me entirely" button |
| 00:41 | <TabAtkins> | "stop nagging me entirely" sounds like "turn off auto-updates entirely" anyway. |
| 00:43 | <zewt> | telling me about an update once (and presumably downloading it for me) is different from disabling update checks outright |
| 00:44 | <TabAtkins> | In practice, not really. Most people will simple forget about it and not update. |
| 00:44 | <zewt> | apple does the same bullshit, and they're more deliberately-obtuse about it--the options are "install now", "remind me in an hour", and "remind me tomorrow" (or something to that effect), which is many miles beyond okay |
| 00:45 | <TabAtkins> | Chrome, of course, just makes the hamburger turn yellow, then red. (And, though my coworkers keep denying it, I swear it also purposely starts breaking audio when you delay too long.) |
| 00:46 | <zewt> | chrome is pretty strict about not making the browser worse when you update, which firefox is not so good about |
| 00:46 | <zewt> | which makes me much less hesitant to let chrome update than firefox |
| 00:46 | <TabAtkins> | Can't comment on that. |
| 00:47 | <zewt> | chrome did basically remove user scripts at one point, which is the only reason I'm still loading firefox at all |
| 00:47 | <zewt> | the biggest breakage on a chrome update that I know of (for my usage patterns) |
| 00:48 | <zewt> | it's depressing that, for all the work people do, the web is unambiguously worse for me today than it was a year or two ago |
| 00:48 | <zewt> | as far as real-world day to day use |
| 01:08 | <roc> | some of that's because of the hard work the bad guys are doing |
| 02:00 | <JonathanNeal> | what’s the hard work the bad guys are doing and who are the bad guys? |
| 02:46 | <JonathanNeal> | roc: ^ |
| 02:54 | <roc> | a ton of browser developer time and energy goes towards blocking the efforts of malware authors and |
| 02:54 | <roc> | "black hat" hackers |
| 02:54 | <roc> | and apart from the opportunity costs, this sometimes results directly in restrictions on what users and Web devs can do |
| 03:50 | <JonathanNeal> | Until things get better, the indie web helps, roc. |
| 03:54 | <caitp> | trying to block the efforts of malware distributors and plugging exploitable holes seems like a suitable thing to spend time on, though |
| 04:12 | <JonathanNeal> | agreed, the web is our new wild west |
| 04:13 | <JonathanNeal> | well, new like the 90’s is still kinda new. |
| 05:34 | <MikeSmith> | annevk: something that's been bugging me about the http://w3c-test.org/encoding/iso-2022-jp-encoder.html and http://w3c-test.org/encoding/gb18030-encoder.html and http://w3c-test.org/encoding/gbk-encoder.html testーthose aren't strictly tests of the encoding spec only, they're actually also tests of the URL. In other words, I couldn't be review/evaluate them just by looking at the Encoding spec, I needed to look at the URL spec too. So I wonder whethe |
| 05:45 | <MikeSmith> | annevk: also about the "iso-2022-jp encoder: SI/SO ESC" test, since nobody passes it and the actual behavior matches in gecko, webkit, and blink (they all return exactly the same thing, even though it doesn't match the spec), I wonder if the spec should change here to match the implementations |
| 05:51 | <MikeSmith> | annevk: or wait is that actually a problem in the test case itself? |
| 06:03 | <MikeSmith> | annevk: so yeah looking back at https://github.com/w3c/web-platform-tests/blob/master/encoding/iso-2022-jp-encoder.html#L12 now, I don't understand why you're doing that res.split("%1B").join("\x1B"). If that step in the test code is omitted, then the test passes as expected. |
| 06:34 | <MikeSmith> | annevk: also r? https://github.com/w3c/web-platform-tests/pull/1383 (minor nit) |
| 07:45 | <annevk> | MikeSmith: r+ |
| 07:46 | <annevk> | MikeSmith: seems you're correct about that, I made a mistake |
| 07:46 | <annevk> | MikeSmith: although if you remove that split().join() line there's a few changes needed earlier too |
| 07:46 | <annevk> | MikeSmith: and there's no way to not have a dependency on either URLs or forms |
| 08:48 | <annevk> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=1093611 is about changing Gecko with respect to URL fragments |
| 08:48 | <annevk> | zcorpan: i.e. align it with Safari and the original RFC |
| 08:48 | <zcorpan> | annevk: ok cool |
| 08:49 | <zcorpan> | annevk: do you know if there's a blink bug? |
| 08:49 | <annevk> | zcorpan: I don't know |
| 08:49 | <annevk> | zcorpan: it's only been fairly recent there's interest in URLs again |
| 08:49 | <annevk> | zcorpan: although in Gecko we're mostly patching a broken setup |
| 08:50 | <annevk> | Hopefully at some point we're going for the rewrite |
| 08:51 | <annevk> | http://jxck.hatenablog.com/entry/whatwg-fetch :-) |
| 08:52 | <zcorpan> | i'll wait and see what happens with that bug |
| 08:55 | <Dashiva> | I feel like there isn't enough "Stop trying to make fetch happen" jokes |
| 08:58 | <annevk> | http://www.hcn.zaq.ne.jp/___/WEB/Fetch-ja.html wow |
| 09:06 | <annevk> | MikeSmith: ah you already merged |
| 09:07 | <annevk> | MikeSmith: thanks, will create a new thing to fix the issue you found |
| 09:34 | <zcorpan> | hmm so firefox developer edition is aurora + a preinstalled extension? |
| 09:36 | <zcorpan> | the name and logo somehow makes me think of opera developer :-) |
| 09:38 | <zcorpan> | i guess it's more inviting than "aurora" which maybe makes people think it's a decease |
| 09:54 | <annevk> | timezone math in Google is nifty |
| 09:54 | <annevk> | I wish it supported "4pm Amsterdam in Toronto" as well |
| 09:54 | <annevk> | I never remember the timezone names |
| 09:55 | <annevk> | 4pm cet in toronto doesn't even work |
| 10:22 | <jgraham> | zcorpan: AIUI "aurora" doesn't exist anymore; the release channels are nightly -> developer -> beta -> stable |
| 10:22 | <jgraham> | But I haven't haven't actually verified that |
| 10:34 | <annevk> | jgraham: looks correct per https://www.mozilla.org/en-US/firefox/channel/#aurora (though note the fragment) |
| 10:37 | <jgraham> | Right, aurora still exists on android, and I doubt we managed to update every externally visible use of the term already |
| 10:39 | <annevk> | I like dbaron's plan of removing beta |
| 10:42 | <jgraham> | Yeah I'm not sure how valuable the 12 week cycle is compared to a 6 week cycle, but I don't have the numbers on how many bugs we fix in that period |
| 10:42 | <jgraham> | Seems like it should be possible to figure out |
| 11:05 | <matijs> | annevk: wolframalpha's got you covered for timezone conversions… http://www.wolframalpha.com/input/?i=4pm+CET+in+toronto |
| 11:05 | <matijs> | sorry… https://www.wolframalpha.com/input/?i=4pm+CET+in+toronto |
| 11:12 | <jgraham> | Yeah, but it's also really slow to load :( |
| 12:02 | <annevk> | I really want Google to support U+XXXX for similar reasons |
| 12:03 | <annevk> | CSS property names and other web developer related aspects would be great too |
| 12:19 | <farnoy> | Hi, is there a way to get canvas composite operation `difference` work on non-100% opacity colors too? |
| 12:19 | <farnoy> | Both `difference` and `xor` seem to work only on 100% opaque areas |
| 12:20 | <annevk> | jgraham: http://wptserve.readthedocs.org/en/latest/response.html is all I need a Python file with a handler definition or is there more to it? |
| 12:24 | <annevk> | farnoy: dev.w3.org/fxtf/compositing-1/#porterduffcompositingoperators_xor is the math, I don't really understand what it does, but if browsers don't match what that says, you might want to file a bug |
| 12:24 | <annevk> | argh address bar |
| 12:25 | <annevk> | hmm UK lunch times |
| 12:42 | <jgraham> | annevk: In my case more like "UK being on a train times" |
| 12:43 | <jgraham> | annevk: Yes, although note that the exact interface there is only needed for difficult cases |
| 12:43 | <jgraham> | In simple cases the main() function can just return a status code / list of headers / body |
| 12:44 | <jgraham> | (the first two are optional) |
| 12:44 | <annevk> | jgraham: the example as is didn't work |
| 12:44 | <annevk> | jgraham: main does seem to work (I copied some stuff from XHR) |
| 12:45 | <jgraham> | annevk: Sorry the documenation is a bit confusing |
| 12:45 | <jgraham> | the main() thing is a feature of web-platform-tests rather than vanilla wptserve |
| 13:03 | <MikeSmith> | annevk: yeah sorry I hadn't checked the iso-2022-jp encoding test carefully enough before I merged it. Thanks for fixing it |
| 13:04 | <MikeSmith> | annevk: also btw I think you'll be glad to know there are now bugzilla components for all the webappsec specs |
| 13:11 | <annevk> | MikeSmith: sweet |
| 13:23 | <annevk> | jgraham: fine to mix async_test and test? |
| 13:27 | <jgraham> | annevk: Yes |
| 13:59 | <annevk> | MikeSmith: https://github.com/w3c/web-platform-tests/pull/1384 |
| 13:59 | MikeSmith | looks |
| 13:59 | <annevk> | jgraham: ^ has the Python file I was asking about |
| 13:59 | <MikeSmith> | ah cool |
| 13:59 | <MikeSmith> | annevk: will review |
| 14:02 | <annevk> | If anyone can think of more things to test with the data I have there, I'd be open to adding more things |
| 14:02 | <annevk> | Actually using the data from the <iframe> is a bit tricky since the HTML parser mangles a couple of bytes |
| 14:02 | <annevk> | Perhaps we should still do that though |
| 14:03 | <annevk> | Probably only affects \x00 and \r |
| 14:04 | <MikeSmith> | annevk: I'd bet zcorpan can think of more things. But it's sometimes dangerous to ask him unless you're prepared to actually do the more things |
| 14:05 | <annevk> | MikeSmith: heh, if it's too much work I'll commit a TODO I guess |
| 14:08 | <jgraham> | MikeSmith++ |
| 14:16 | <Ms2ger> | MikeSmith++ |
| 14:17 | <Ms2ger> | zcorpan++ |
| 14:17 | <zcorpan> | what did i do? |
| 14:17 | <Ms2ger> | Think of more things to test, for as long as I can remember :) |
| 17:20 | <caitp> | so how is the "please address our issues with custom elements / shadow dom / etc" thing coming? I'd love to be CC'd on such bugs if possible |
| 17:29 | <annevk> | caitp: you could go through the open bugs and copy yourself ;) |
| 17:29 | <caitp> | it's impossible to find anything in there :( |
| 17:31 | <annevk> | caitp: anything recent you can find on public-webapps, as it's copied when a new bug is filed |
| 17:44 | <TabAtkins> | annevk: What do you mean by "support u+xxxx"? Show a onebox for it? |
| 17:44 | <annevk> | TabAtkins: if that's what it's called |
| 17:44 | <TabAtkins> | Yeah, dunno where the terminology comes from. |
| 17:44 | <TabAtkins> | I just always click the filesystem.info link. ^_^ |
| 17:45 | <annevk> | TabAtkins: me too, but if I just want to copy-and-paste the actual code point, it could be easier... |
| 17:45 | <TabAtkins> | true that. |
| 17:45 | <TabAtkins> | We've got a thing to suggest new onebox results. I'll ping. ^_^ |
| 17:46 | <annevk> | TabAtkins: heh, can you ask about "4pm Amsterdam in Toronto"? |
| 17:46 | <TabAtkins> | heh, k. |
| 17:47 | <TabAtkins> | (I always just ask for "time in toronto" and then add/subtract hours from current time as necessary.) |
| 17:47 | <annevk> | TabAtkins: it seems some timezone support was rolled out, but it's fairly US-centric, e.g. not even "4pm cet in toronto" works |
| 17:47 | <annevk> | "4pm pst in toronto" works |
| 17:47 | <annevk> | so weird |
| 18:47 | <annevk> | JakeA: how much would you mind if I removed all the hyphens from https://fetch.spec.whatwg.org/#requestmode ? |
| 18:47 | <annevk> | JakeA: apparently there's precedent for enumerations to be lowercase and no hyphens |
| 18:51 | <Hixie> | zcorpan: you have some sort of syntax error in your picture stuff |
| 18:52 | <Hixie> | search for "<var>image request</span>" |
| 18:52 | <JakeA> | annevk: I'll ask the engineers how difficult it is to get a patch in for that. Will let you know. |
| 18:53 | <annevk> | JakeA: to be clear, from all enum productions |
| 18:54 | <JakeA> | annevk: everything in fetch right? So no-cors to nocors etc |
| 18:54 | <annevk> | JakeA: yup |
| 18:54 | <annevk> | ta |
| 19:00 | <JakeA> | annevk: I mean, hyphens seem loads better in terms of usability (or camelCase, whatever) |
| 19:00 | <annevk> | Hixie: opinion? |
| 19:01 | <Hixie> | on? |
| 19:01 | <annevk> | Hixie: enum naming |
| 19:01 | <annevk> | Hixie: e.g. arraybuffer vs arrayBuffer vs array-buffer |
| 19:01 | <Hixie> | you mean strings in JS used as arguments? |
| 19:01 | <annevk> | yes |
| 19:01 | <Hixie> | if they're not used as identifiers, i'd just go with readable strings, e.g. "fat array" |
| 19:01 | <annevk> | I think it's mostly justonelongstring |
| 19:02 | <Hixie> | but i view "arraybuffer" as one word, so... |
| 19:02 | <Hixie> | i definitely wouldn't camelcase in a string |
| 19:05 | <annevk> | "no cors" |
| 19:05 | <annevk> | hmm |
| 19:05 | <zcorpan> | Hixie: thanks, fixed |
| 19:05 | <annevk> | but then same origin or same-origin... |
| 19:05 | <annevk> | baaah |
| 19:05 | <Hixie> | zcorpan: coolio, regenning... |
| 19:06 | <caitp> | if something is not documented, nobody depends on it and you're free to break it in any way you see fit |
| 19:07 | <Hixie> | hahaha |
| 19:07 | <Hixie> | no |
| 19:07 | <caitp> | you're getting good at reading my sarcasm |
| 19:08 | <annevk> | caitp: well, you also suggested we could still change HTML parsing rules |
| 19:08 | <caitp> | i think it would be good to change it |
| 19:08 | <caitp> | i wouldn't say it wouldn't break anyone =) |
| 19:10 | <caitp> | more just that I don't really care if people get broken due to depending on bogus misfeatures |
| 19:10 | <caitp> | :c |
| 19:11 | <jarek> | is something like "new HTMLDivElement()" supposed to work? |
| 19:11 | <annevk> | jarek: nope |
| 19:11 | <caitp> | not afaik |
| 19:12 | <jarek> | at least on Chrome I can do "new DocumentFragment()", so I would expect other DOM APIs to have usable constructors as well |
| 19:12 | <annevk> | jarek: you can tell by the lack of [Constructor] |
| 19:12 | <caitp> | i think there have been some arguments that it "should" work, though |
| 19:12 | <annevk> | jarek: that's because I gave DocumentFragment a constructor: https://dom.spec.whatwg.org/#interface-documentfragment |
| 19:12 | <jarek> | annevk: I see, but there is nothing stopping WHATWG from adding the constructor in near future? |
| 19:13 | <annevk> | jarek: it's a bit hard for elements, since some interfaces are used for several elements |
| 19:13 | <jsbell> | What's WebIDL for "return type of a method that returns a promise that will fulfil to undefined"? Promise<void> or ... ? |
| 19:13 | <annevk> | jsbell: yes |
| 19:13 | <jsbell> | annevk: thx |
| 19:15 | <jarek> | annevk: but those are abstract interfaces, right? |
| 19:15 | <jarek> | on Chrome it's also possible to use "new" with custom element class that inherits from HTMLDivElement and has no constructor |
| 19:16 | <Ms2ger> | new HTMLDivElement()... Ugh |
| 19:16 | <Ms2ger> | Whatever happened to Element.create()? |
| 19:16 | <annevk> | Ms2ger: got too complex |
| 19:16 | <jarek> | Ms2ger: what's wrong with "new" approach? Factory pattern was cool 10 years ago |
| 19:17 | <Ms2ger> | jarek, the interface name is awful |
| 19:17 | <annevk> | jarek: the problem with the new approach is abstract interfaces (e.g. HTMLHeadingElement) and the verbosity |
| 19:17 | <Ms2ger> | jarek, and we have a localName <-> interface correspondence that makes that weird too |
| 19:18 | <caitp> | in 20 years, it will all be different, or irrelevant |
| 19:19 | <caitp> | pick one |
| 19:19 | <jarek> | Ms2ger: it's more generally HTML <-> JS correspondence |
| 19:19 | <annevk> | jarek: I don't think there's much opposition per se btw |
| 19:19 | <Ms2ger> | jarek, I don't follow that |
| 19:19 | <jarek> | Ms2ger: in JS I want to use constructors and in HTML localNames |
| 19:19 | <annevk> | jarek: it's just coming up with a good story that works for all elements |
| 19:20 | <annevk> | jarek: e.g. that is why new DocumentFragment works, but new Element does not (yet?) |
| 19:20 | <jarek> | annevk: I think Dart already does it (via some heavy wrappers) |
| 19:21 | <annevk> | jarek: it isn't immediately obvious how you'd create an element {test, test} other than createElementNS("test", "test") |
| 19:22 | <annevk> | jarek: and if you were to suggest new Element("test", "test") that'd be somewhat weird as new Element("http://www.w3.org/1999/xhtml";, "div") would return HTMLDivElement... |
| 19:22 | <jarek> | annevk: isn't createElementNS going to be depracated? |
| 19:22 | <jarek> | I thought the plan was to move SVG and MathML into HTML namespace |
| 19:22 | <annevk> | jarek: ah yeah, I guess that's still somewhat a plan Google has |
| 19:25 | <jarek> | all new geometry interfaces (DOMMatrix, DOMPoint, DOMRect) are created with "new" rather than factories |
| 19:26 | <Ms2ger> | That seems like too much pain for too little gain |
| 19:26 | <jarek> | and the spec says that "new SVGMatrix" should also work because SVGMatrix should just reference DOMMatrix |
| 19:28 | <annevk> | jarek: sure, new objects use constructors |
| 19:29 | <annevk> | jarek: but as long as there's no plan for existing objects, nothing will happen |
| 20:11 | <TabAtkins> | The attempt to move SVG into the HTML namespace isn't a "Google" thing, it's a "me" thing, and the SVGWG explicitly agreed to try and do it at the last meeting, if possible. |
| 20:13 | <caitp> | what difference would it make exactly? let people create SVG elements with createElement() instead of createElementNS() ? |
| 20:13 | <caitp> | seems like it wouldn't work with <a> |
| 20:13 | <TabAtkins> | Yes, and making it a little less weird to intermix them more freely (putting <video>, <input>, etc inside of SVG) |
| 20:14 | <TabAtkins> | <a> is fine - SVG2 is dropping xlink:href in favor of href, so the elements'll match. |
| 20:14 | <TabAtkins> | <script> and <style> similarly can be merged. |
| 20:14 | <caitp> | so just getting rid of SVGAElement and using HTMLAnchorElement instead? |
| 20:14 | <TabAtkins> | And now that SVG Fonts are dropped, just using the HTML <font> is fine. That's all the clashes. |
| 20:14 | <TabAtkins> | Yeah. |
| 20:14 | <TabAtkins> | That's the *hope*. |
| 20:15 | <annevk> | TabAtkins: sorry for misattribution |
| 20:17 | <TabAtkins> | annevk: No problem, I just don't like too many things getting attributed as "google stuff", because that plays into certain paranoid narratives. |
| 20:17 | <caitp> | so then what happens to everyones SVGAElements that do in fact use xlink stuff :p |
| 20:18 | <annevk> | TabAtkins: Google will burn for destroying namespaces |
| 20:18 | <TabAtkins> | SVG will allow xlink:href still, it'll just be lower-priority than href. |
| 20:18 | <annevk> | caitp has a point though that you cannot have both |
| 20:18 | <annevk> | Unless you make xlink:href work in HTML too... |
| 20:19 | <TabAtkins> | Some bleed-through back into HTML might be okay. Or maybe we can hackily make xlink:href only work if there's an <svg> ancestor. |
| 20:26 | <caitp> | plus people would be like "hey this used to be an instance of SVGAElement but now it's not what happened" |
| 20:27 | <caitp> | i mean, it gets a bit murky I think |
| 20:27 | <caitp> | cool though |
| 20:30 | <gsnedders> | sure! |
| 20:31 | <TabAtkins> | We're somewhat concerned about code that uses "is this in the SVG namespace?" to do something special. |
| 20:31 | <TabAtkins> | We know that a decent chunk of code is for papering over differences in basic DOM operations between SVG and HTML elements, and now that most (and eventually all?) are consistent, having that sort of code go down the HTML path will be fine. |
| 21:10 | <Hixie> | in the ES6 iterator protocol, can done ever be true with value being set to some useful value? |
| 21:10 | <Hixie> | or is it always either done, or value? |
| 21:21 | <TabAtkins> | A *valid* iterator won't ever do that. |
| 21:21 | <TabAtkins> | You can make a custom iterator that violates the constraints, but that's your fault then. |
| 21:24 | <caitp> | from https://github.com/v8/v8-git-mirror/blob/d3d29c640cf14f0eac2057b4fbffa5fbc0a29231/src/x64/full-codegen-x64.cc#L1242-L1281, it looks like it's a `done or value` scenario, haven't checked the spec |
| 21:24 | <Hixie> | right, i mean according to the protocol |
| 21:24 | <Hixie> | k |
| 21:24 | <TabAtkins> | Yeah, a valid iterator only ever produces a {value} object or a {done} object. |
| 21:25 | <TabAtkins> | (Or {value: foo, done: false}, of course.) |
| 21:26 | <caitp> | i guess technically you could return anything you wanted from @@iterator though |
| 21:26 | <TabAtkins> | Yeah, and then it's your fault for getting possibly-confusing results. |
| 21:26 | <caitp> | were you inclined to confuse the vm |
| 21:39 | <annevk> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iteratorresult-interface |
| 21:40 | <Hixie> | man the ES6 iterator protocol really makes it a pain to work out if you're dealing with the last item in the list |
| 21:41 | <annevk> | I suspect if you use a language feature you don't really have that problem |
| 21:41 | <TabAtkins> | Languages that make it easier for the consumer end up being *way* harder for the producer. There was a lot of argument over this originally. |
| 21:42 | <Hixie> | yeah |
| 21:42 | <Hixie> | well |
| 21:42 | <Hixie> | either way :-) |
| 21:42 | <TabAtkins> | (You generally end up having to duplicate code between isEnded() and next(), or pre-compute next() to see if it's at the end and stash it away.) |
| 21:42 | <Hixie> | (personally i always prefer to make it harder on the producer) |
| 21:42 | <TabAtkins> | I've found that, while a "late end" is a little harder for the consumer, it's not a huge deal, and sometimes easier. |
| 21:42 | <Hixie> | (since there are fewer of those) |
| 21:43 | <TabAtkins> | Chaining iterables, for example, is slightly simpler, at least to me, with a late end. |
| 21:43 | <annevk> | Why is it hard btw? Just check if done is true? |
| 21:44 | <TabAtkins> | Hixie: Also, sometimes you *can't* early-end, while you can always late-end. For example, your iterable might be lazily pulling stuff off the server. |
| 21:44 | <Hixie> | annevk: say you want to add all the numbers in an iteration except hte last one |
| 21:44 | <Hixie> | TabAtkins: *shrug* i'm just saying it's a pain. not making a counter-proposal. |
| 21:45 | <TabAtkins> | Hixie: Yeah, I know. I'm just providing more reasons why it was done the way it was, despite the pain. |
| 21:45 | <caitp> | do we have generator-iterators? |
| 21:45 | <TabAtkins> | Yes. |
| 21:45 | <caitp> | huh. |
| 21:45 | <TabAtkins> | Why "huh"? |
| 21:45 | <annevk> | while iterval.done != true ...? |
| 21:45 | <caitp> | i'm just imagining that working in a for...of context |
| 21:46 | <TabAtkins> | annevk: If you want all *but* the last, you have to specially stash the last one you've seen, and only add it in the *next* iteration if you're not done yet. |
| 21:46 | <caitp> | which is the way everyone ought to want to use iterators, because it's nice :( |
| 21:46 | <TabAtkins> | Though this isn't a big deal - if you want all but the last *two*, you have to do something like this regardless of early/late end. |
| 21:46 | <TabAtkins> | caitp: generators work fine in for-of. What problem are you thinking about? |
| 21:46 | <Hixie> | TabAtkins: yeah iterators in general have this problem, basically |
| 21:47 | <Hixie> | TabAtkins: as opposed to access by index |
| 21:47 | <TabAtkins> | Hixie: Of course, you can abstract this away with an iterator combinator that drops the last N elements. It needs to seek ahead N elements, of course, but that's what you'd be manually doing anyway. |
| 21:48 | <annevk> | TabAtkins: why do you have to wait for the next value? It tells you whether more is coming, no? |
| 21:48 | <TabAtkins> | Then you can just do itersum(dropLast(1, iter)) |
| 21:48 | <Hixie> | TabAtkins: interesting idea |
| 21:48 | <TabAtkins> | annevk: No. You either have a "value" frame, or a "done" frame. |
| 21:48 | <TabAtkins> | You don't know it's done until you ask for the next value and get a "done" frame instead. |
| 21:48 | <Hixie> | TabAtkins: probably not great for perf, but if it's not hot code, could work |
| 21:48 | <annevk> | TabAtkins: ah sorry |
| 21:48 | <TabAtkins> | Hixie: When working with iterators, more combinators is always the right answer. They're easy to code up and easy to use. |
| 21:49 | <annevk> | TabAtkins: I see it now |
| 21:49 | <annevk> | thanks |
| 21:49 | <TabAtkins> | Hixie: It's the same thing you'll be doing manually, so I dont' see the perf concern (except for more function calls, I suppose.) |
| 21:49 | <Hixie> | TabAtkins: function calls can be expensive, depending on the language |
| 21:50 | <TabAtkins> | Sure. Those languages aren't very good for iterator-based code, which is heavily functional. |
| 21:51 | <Hixie> | i have profiled this in JS, so i don't know what the overhead would be |
| 21:52 | <Hixie> | i wouldn't be surprised if it was measurable, though |
| 21:52 | <annevk> | Hixie: you're actually writing JS these days? |
| 21:53 | <Hixie> | i often write js code :-P |
| 21:53 | <Hixie> | our whole platform uses js :-P |
| 21:53 | <Hixie> | but in this instance, i'm basically trying to learn all the new stuff to get more up to date |
| 21:54 | <caitp> | [16:46] <TabAtkins> caitp: generators work fine in for-of. What problem are you thinking about? <<< well it's not generators that are the issue really, but in my head i'm expecting async iterators would be likely to use them --- but mostly it's the whole "async for-of" that i'm talking about, does that work? |
| 21:54 | <caitp> | it's hard to verify in d8, so I'm not sure |
| 21:55 | <TabAtkins> | Ah, async generators will produce promises. Consuming that directly with a for-of is obviously tricky, unless you really want to work with promises (which you might). Along with async/await there's a proposal for an asynchronous version of for-of that handles async generators transparently. |
| 21:56 | <TabAtkins> | (And I think it just returns promises of iterator frames, so using for-of over an async generator won't be useful, as it'll produce an infinite list.) |
| 21:58 | <caitp> | infinite lists don't sound very useful, no |
| 21:59 | <TabAtkins> | They're very useful. Just not in a for-of when you can't actually verify where to manually break. |
| 21:59 | <TabAtkins> | Like, I've used prime number generators before - clearly infinite. |
| 22:00 | <TabAtkins> | Or just infinite ranges. |
| 22:01 | <TabAtkins> | Frex, Bikeshed's ID deduping appends an int to the end fo the ID to make it unique. It just creates an infinite list starting from 0 and iterators until it finds a non-clashing one. |
| 22:04 | <TabAtkins> | s/ors/es/ |
| 22:06 | <Hixie> | is "let x; let x;" valid? |
| 22:06 | <Hixie> | "var x; var x;" is |
| 22:06 | <Hixie> | though the second "var x" does sod all |
| 22:06 | <TabAtkins> | I don't *think* it is, but I'm not sure. |
| 22:07 | <TabAtkins> | var has stupid scoping and nobody cares about it. |
| 22:07 | <Hixie> | i care about it, but ok |
| 22:09 | <Domenic> | let x; let x; is not valid |
| 22:09 | <Hixie> | k |
| 22:09 | <Domenic> | in fact var x; let x; is not valid |
| 22:09 | <Hixie> | sure that makes sense |
| 22:11 | <TabAtkins> | let x; if(...) { let x; } *is* valid, though. |
| 22:11 | <TabAtkins> | New scope. |
| 22:11 | <TabAtkins> | (As is putting the let inside the if condition - it shares scope with its contents.) |
| 22:11 | <Hixie> | sure |
| 22:11 | <Hixie> | the case i was looking at was: |
| 22:12 | <Hixie> | let x = 0; while (...) { ... } |
| 22:12 | <Hixie> | let x = 0; while (...) { ... } |
| 22:12 | <Hixie> | where it would be aesthetically pleasing for the let to be valid |
| 22:12 | <Hixie> | but it's just as easy to do: |
| 22:12 | <Hixie> | let x; |
| 22:12 | <Hixie> | x = 0; while (...) { ... } |
| 22:12 | <Hixie> | x = 0; while (...) { ... } |
| 22:13 | <jyasskin_> | for (let x = 0; ...; ) {...} ? |
| 22:13 | <Hixie> | x isn't in the while loop |
| 22:13 | <Hixie> | er |
| 22:13 | <Hixie> | in the condition |
| 22:13 | <Hixie> | it's just an accumulator |
| 22:13 | <Hixie> | or similar |
| 22:13 | <Hixie> | or a state boolean |
| 22:13 | <Hixie> | or any number of other things |
| 22:14 | <TabAtkins> | Yeah, you just can't do the repeated let. Do it once and set it twice, instead. |
| 22:16 | <Hixie> | classes have no syntax for value properties, right? you have to create the property in the constructor? |
| 22:16 | <Hixie> | and there's no privates in classes? not even using Symbols? |
| 22:16 | <TabAtkins> | Value properties being "properties on the instance"? |
| 22:17 | <TabAtkins> | And what do you mean by "private", specifically? That term is wrapped up in a lot of language-specific baggage, just like "class". ^_^ |
| 22:19 | <jsbell> | { let x = 0; while (...) { ... } } |
| 22:23 | <Hixie> | TabAtkins: value properties meaning values without getters or setters, which in the case of JS would be on the instance, yes |
| 22:23 | <Hixie> | by "private" i mean "not accessible to code outside the class" |
| 22:23 | <TabAtkins> | Yes, instance properties are done in the constructor. |
| 22:24 | <TabAtkins> | You can implement private state by using WeakMaps. |
| 22:25 | <TabAtkins> | (And that'll be easier to use when we figure out relations and their syntax.) |
| 22:25 | <Hixie> | how do you do private state with weakmaps? |
| 22:26 | <TabAtkins> | You use the instance as the key, and the state as the value. Then you use standard closure-based data-hiding to only expose the weakmap to the class's own methods. |
| 22:27 | <Hixie> | how do you do the latter? |
| 22:27 | <Hixie> | (also, that's really ugly) |
| 22:28 | <TabAtkins> | (function(){ let x = new WeakMap(); class foo { ... }; })() |
| 22:28 | <Hixie> | wouldn't "foo" also be non-visible then |
| 22:28 | <TabAtkins> | You can return it. |
| 22:28 | <Hixie> | ... |
| 22:28 | <TabAtkins> | var foo = (...) |
| 22:29 | <gsnedders> | Hixie: this is what everyone does |
| 22:29 | <TabAtkins> | Some form of "real" private state would involve reifying classes more than we wanted to do at this point. Maximin classes passed because they're sugar over the existing system. |
| 22:29 | <Hixie> | well, nobody actually does this |
| 22:29 | <Hixie> | since class { } doesn't work yet |
| 22:29 | <Hixie> | but also, everyone says js sucks |
| 22:29 | <Hixie> | i was assuming we were trying to fix that :-) |
| 22:30 | <TabAtkins> | They (and by that I mean, at least I) do this today with .prototype munging code. |
| 23:00 | <Hixie> | annevk: is there a reason to do https://www.w3.org/Bugs/Public/show_bug.cgi?id=27315 other than editorial clarity? |
| 23:06 | <caitp> | Hixie: enum will limit the values that can be assigned, whereas DOMStrings won't, so that's useful maybe |
| 23:06 | <caitp> | i mean, I guess it's kind of the same, but not really? |
| 23:06 | <caitp> | probably a good idea at any rate |
| 23:07 | <Hixie> | the spec already doesn't allow invalid values to be assigned |
| 23:07 | <Hixie> | so that's not a difference |
| 23:08 | <caitp> | well if browsers are implementing it as enums then there isn't much difference |
| 23:08 | <caitp> | but if they are then even if it's not a real difference, it would align better with reality? |
| 23:09 | <caitp> | i dunno |
| 23:09 | <TabAtkins> | The editorial clarify of enums is useful. |
| 23:09 | <Hixie> | yes, that much is clear |
| 23:09 | <Hixie> | the question is whether this is just an editorial change, or more than that |
| 23:10 | <Hixie> | since if it's just editorial, then i can punt it to 2018, if it's something that actually matters, i should look at it now... |
| 23:12 | <caitp> | well it sounds like you've decided that it doesn't really matter already, anyway it's time to stop caring about the internet and go make supper. |
| 23:16 | <Hixie> | i haven't decided anything, that's why i was asking |
| 23:19 | <Hixie> | if i say: |
| 23:19 | <Hixie> | foo.Bar = class Bar extends Baz { }; |
| 23:19 | <Hixie> | does it declare Bar in the local scope? |
| 23:19 | <Hixie> | as in, can the next line be: |
| 23:19 | <Hixie> | let quux = new Bar(); |
| 23:20 | <Domenic> | I am 90% sure it does not, but it does declare Bar inside the class body |
| 23:20 | <Hixie> | or does using it in an expression mean that only foo.Bar is set to the class? |
| 23:22 | <MikeSmith> | caitp: you're implementing js template strings in v8? |
| 23:22 | <Hixie> | i'm pretty sure the answer is in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-runtime-semantics-evaluation somewhere |
| 23:23 | <Hixie> | i think steps 7 and 8 of the first part not being in the second part means the answer is "no" |
| 23:23 | <jorendorff> | Domenic is right, it's just like a function |
| 23:23 | <jorendorff> | there is a Bar binding, but only within the scope of the class itself |
| 23:23 | <jorendorff> | not the enclosing scope |
| 23:24 | <TabAtkins> | Domenic: Hm, I thought it did. I thought you could declare anonymous classes to avoid that. |
| 23:24 | <Hixie> | ok i'm pretty sure the spec supports jorendorff and Domenic here |
| 23:24 | <Hixie> | (pity) |
| 23:24 | <TabAtkins> | I didn't actually know that `var foo = function bar(){};` didn't also declare a local "bar" variable. |
| 23:25 | <jorendorff> | it used to in IE :) |
| 23:25 | <jorendorff> | at least, i think it did - there was some horrible bug or other |