| 05:45 | <KiChjang> | help on MessagePort? |
| 05:58 | <annevk> | KiChjang: what do you mean by disabled? close() is called? |
| 05:58 | <KiChjang> | annevk, its initial state when it was created |
| 05:58 | <KiChjang> | the spec says it's initially disabled |
| 05:59 | <annevk> | KiChjang: it doesn't say that about the port, it says that about its message queue |
| 05:59 | <KiChjang> | so in other words, if i queue a message task before start() is called, what happens? |
| 05:59 | <KiChjang> | does the port buffer the task? |
| 05:59 | <annevk> | KiChjang: the queue does |
| 06:00 | <KiChjang> | and when the queue itself is enabled, it would then fire the tasks off to their targets? |
| 06:01 | <annevk> | KiChjang: yeah, that's the intent, I have to say I've a hard time reading the spec as well |
| 06:01 | <KiChjang> | does the same happen for the has_been_shipped flag as well? |
| 06:01 | <annevk> | KiChjang: it could use some more refactoring maybe, though Domenic just improved some parts of this by redoing transfering and such |
| 06:03 | <KiChjang> | as in, the tasks also get buffered if the has_been_shipped flag is unset, and they would only be fired when it's set? |
| 06:03 | <KiChjang> | in which case, that would sound like enabling/disabling and the has_been_shipped flag does the exact same thing |
| 06:06 | <annevk> | KiChjang: I'm sorry, I don't think I understand the standard from a quick read |
| 06:07 | <annevk> | KiChjang: as I said, this might be worthy of some refactoring |
| 06:08 | <KiChjang> | annevk, ah ok, good thing i brought it up |
| 06:08 | <KiChjang> | shall i file an issue? |
| 06:09 | <annevk> | KiChjang: yeah |
| 06:09 | <annevk> | KiChjang: did you look for tests already? |
| 06:09 | <annevk> | KiChjang: might be handy to link any available tests too |
| 06:09 | <KiChjang> | annevk, yeah, that might clarify the behaviour a bit as well |
| 06:09 | <KiChjang> | i was purely looking to implement it |
| 08:46 | <zcorpan> | MikeSmith: https://github.com/validator/validator/pull/477 |
| 09:04 | <tobie> | annevk: looking at https://github.com/whatwg/infra/issues/13 |
| 09:04 | <tobie> | annevk: and just to make sure I understand the context clearly— |
| 09:05 | <tobie> | annevk: what you're looking for is an underlying data structure, not something that would end up in WebIDL, right? |
| 09:06 | <annevk> | tobie: just a convention I guess |
| 09:08 | <tobie> | annevk: so you could say something like: "a URL that has an origin example.com" ? |
| 09:09 | <tobie> | annevk: I'm basically trying to figure out whether this intersects with having a syntax for slots |
| 09:13 | <annevk> | tobie: just so that URL records and such are grounded somehow |
| 09:14 | <annevk> | tobie: slots are only for objects |
| 09:14 | <annevk> | tobie: a slot could hold such a tuple though I suppose |
| 09:20 | <Domenic> | An example is fetch |
| 09:20 | <Domenic> | A Response holds a response which is probably a tuple |
| 09:20 | <Domenic> | (sometimes known as a "concept-response" after it's #anchor) |
| 09:25 | <tobie> | looking |
| 09:29 | <tobie> | Mmm. In 1 <=> 1 relationships between concepts and WebIDL interfaces, I think I've been merging the two things and using slots as concept fields. |
| 09:30 | <tobie> | This might be a bad idea? |
| 09:31 | <tobie> | ^ Domenic, annevk |
| 09:42 | <annevk> | tobie: no seems good for same instance |
| 09:43 | <annevk> | tobie: maybe not if not merged into one |
| 09:43 | <annevk> | tobie: out for a couple hours now |
| 09:57 | <tobie> | annevk: (when you're back—no hurry) how is this different for URL or response? Don't you have a 1:1 mapping? |
| 10:14 | <Domenic> | This seems kinda confused to me... an object has a slot which stores a concept. The concept then has lots of fields. This is useful when the concept is an independently useful entity like a response or URL. |
| 10:15 | <Domenic> | In other cases where there is no independently useful concept an object can have many slots |
| 10:19 | <tobie> | Domenic: wasn't suggesting absence of confusion. Quite the opposite actually. :) |
| 10:19 | <tobie> | Domenic: I guess what I was poking at was whether concepts would still exist if we had a good story for slots. |
| 10:20 | <tobie> | Domenic: sounds like the answer is yes. |
| 10:20 | <Domenic> | Yeah, they're what you store in the slots |
| 10:21 | <tobie> | Domenic: s/what/one of the things/ right? |
| 10:21 | <Domenic> | right :) |
| 10:21 | <tobie> | Domenic: not being pedantic, just making sure we're in agreement. :) |
| 10:22 | <tobie> | Domenic: so fields are slots for concepts, right? |
| 10:23 | <Domenic> | yeah, or for tuples at least. Although i'm not sure we've settled on the name "fields". |
| 10:24 | <Domenic> | Basically these are all different names for "properties" that are intentionally different so as to be less confusing. But maybe it is making it more confusing :P |
| 10:25 | <Domenic> | I guess the main reason "internal slot" and "property" are different is because they can live on the same thing, a JS/Web IDL object. (Although Web IDL calls them "attributes" instead of properties for... reasons.) |
| 10:25 | <tobie> | yes, the distinction in WebIDL makes sorta sense |
| 10:31 | <tobie> | What I don't understand from infra issues 13 and 21 is why do we want to give this abstract structure for concepts concrete qualities such as a fixed sized. |
| 10:37 | <Domenic> | I mean... would you rather them have an unfixed size? |
| 10:48 | <tobie> | :D |
| 10:48 | <tobie> | No, I'm basically just wondering why we need an extra structure if maps are otherwise a good solution to map concepts. |
| 10:49 | <tobie> | (pun not intended) |
| 11:05 | <Domenic> | Well, it's the same reason that in languages we have classes/structs and not just hash maps |
| 11:05 | <Domenic> | Sure you can represent everything as a hash map. But it's important to give names to certain types, to say their shape is always a certain way, that they can be treated as a class, that their keys are always strings, that certain operations operate on them.... |
| 11:21 | <jgraham> | Just tell tobie that hashmaps-everywhere are basically what Python does. I imagine he will find that convincing ;) |
| 11:21 | <jgraham> | (but ofc python does actually provide syntax over the hashmaps for the reasons that Domenic explains) |
| 11:22 | <tobie> | jgraham: the only thing I truly dislike about python is significant whitespace |
| 11:22 | <tobie> | feels gimmicky |
| 11:24 | <tobie> | Coming from JS (and before that, Ruby), hashmaps everywhere has a distinct homeland flavor |
| 11:26 | <tobie> | To come back to the issue at hand—I guess I'm sort of concerned that we're basically adding an lower-level type system to something that's already a lower-level type system to JS |
| 12:25 | <gsnedders> | do shared workers and service workers expose the exact same things as normal workers? |
| 12:27 | <Domenic> | gsnedders: no, you can use Exposed=SharedWorker or ServiceWorker or similar. |
| 12:27 | <Domenic> | And people do, especially for service |
| 12:28 | <gsnedders> | Domenic: thx |
| 12:31 | <gsnedders> | Domenic: but everything exposed on Worker is exposed in Shared/ServiceWorker? Where is that defined? |
| 12:31 | <MikeSmith> | zcorpan: yeah saw that validator PRーthanks. I just need to check out the branch and test it before merging. Will try to do that by tomorrow |
| 12:34 | <zcorpan> | MikeSmith: ok cool. i have tested it locally, fwiw |
| 12:35 | <nox> | I see that /websockets/interfaces/WebSocket/close/close-connecting.html doesn't pass in both Firefox and Safari, should I report that? |
| 13:17 | <annevk> | nox: yeah probably |
| 13:42 | <nox> | Ok. |
| 14:13 | <annevk> | tobie: sorry for short answers earlier, was trying to answer while walking around |
| 14:14 | <tobie> | annevk: no worries. :) |
| 14:14 | <annevk> | tobie: we basically invent new data structures for ease of notation or clarity on scope |
| 14:15 | <tobie> | annevk: not sure what you mean by clarity on scope, here. |
| 14:15 | <annevk> | tobie: both of those seem worthwhile and it also seems okay to have more types than JavaScript does at the moment, since JavaScript is still evolving as well |
| 14:15 | <annevk> | tobie: basically what can happen to the data structure, how it can be manipulated, which aspects can change, etc. |
| 14:16 | <tobie> | annevk: ok |
| 14:19 | <tobie> | annevk: Isn't what you need a struct? |
| 14:20 | <annevk> | tobie: maybe if that's like a tuple without order that'd be good, but that's also what JavaScript's Record type is I believe |
| 14:21 | <annevk> | tobie: maybe JavaScript's Record type is all we really need and we should just give up on tuples, although Records are oddly flexible sometimes in that they get extra fields |
| 14:22 | <tobie> | annevk: tuples don't have a key-value concept, though, do they? |
| 14:22 | <annevk> | tobie: they do in Infra's PR |
| 14:23 | <tobie> | so they're not *really* tuples, then |
| 15:12 | <annevk> | tobie: Python has named tuples |
| 15:12 | <tobie> | annevk: wat |
| 15:26 | <jgraham> | tobie: from collections import namedtuple |
| 15:26 | <jgraham> | It's a type that has ordered fields |
| 15:26 | <jgraham> | I mean it's a bit weird but not that weird because python allows destructuring tuples but not objects |
| 15:26 | <jgraham> | s/objects/other classes/ I guess |
| 15:27 | <jgraham> | Also it's the only immutable collection type |
| 15:28 | <jgraham> | So I guess you could say it is weird but only in the sense that Python was already weird here and we should all be using Standard ML or something |
| 15:36 | <annevk> | That wouldn't be normal either! |
| 16:07 | <nox> | Can someone help me walk through /websockets/cookies/007.html? |
| 16:28 | <gsnedders> | nox: probably zcorpan's test originally, fwiw |
| 16:31 | <Younder> | been watching Blink on 7 |
| 16:33 | <Younder> | nice to see you are focusing on function instead of feature. No 1990 repeat. (worse is better) |
| 21:34 | <jyasskin> | The "current settings object" is the "relevant settings object" of the function that's currently executing, right? |