| 02:10 | <Domenic> | jugglinmike: we prefer explicit callbacks these days, like we've done for all other WebDriver BiDi hooks. |
| 02:10 | <Domenic> | In particular, this helps get the ordering clear. |
| 02:10 | <Domenic> | Not sure what hooks you're referring to that already exist, although it's a long section so maybe I just missed them |
| 02:11 | <Domenic> | Oh you mean the many specific ones, not a generic one. |
| 09:06 | <sbastiandev> | Hello All, |
| 09:09 | <sbastiandev> | I am almost done implementing the latest URL Spec in Java and was wondering if the various URL's setters should throw Exceptions when something goes wrong ? I read the specification and didn't find anything on this ? Can anyone shed some light ? Thx a lot |
| 10:24 | <Noam Rosenthal> | sbastiandev: judging by this note: https://url.spec.whatwg.org/#validation-error whether validation errors throw is left to the user agent |
| 10:28 | <Noam Rosenthal> | as in, the web platform doesn't throw on validation errors (based on the note, for backwards compatibility), but conformance checkers probably should. Makes sense to me that this is a library/platform decision rather than spec decision. probably some people here with more context though |
| 12:36 | <sbastiandev> | sbastiandev: judging by this note: https://url.spec.whatwg.org/#validation-error whether validation errors throw is left to the user agent |
| 12:46 | <Noam Rosenthal> | sbastiandev: if you see the setter algorithm, those do something and then call the parsing algorithm and some parsing leads to validation errors, which leads back to this note |
| 12:46 | <Noam Rosenthal> | (setter algorithms) |
| 12:48 | <Noam Rosenthal> | e.g. "The protocol setter steps are to basic URL parse the given value, followed by U+003A (:), with this’s URL as url and scheme start state as state override." |
| 14:57 | <jugglinmike> | Thanks Domenic ! |
| 15:03 | <Dominic Farolino> | Can you define a custom conversion from arbitrary ES types to your specific IDL type? Like, if I have an interface, and I want methods that accept objects of that interface type to also accept a handful of other types that my native interface type can be constructed from, how can I do this? Do those methods have to accept any, and then I just write their dfn as delegating to an internal conversion algorithm that I provide? Or can I just accept MyInterface types, and specify some some conversion algorithm that gets invoked whenever anything is passed in as a MyInterface? |
| 15:04 | <Dominic Farolino> | I think I'm interested in simulating something like the WebIDL Promise type, which accepts all thenables but also native Promises, IIUC |
| 15:05 | <Dominic Farolino> | (Context is for https://github.com/domfarolino/observable, where it'd be nice for methods that accept an Observable to also accept Async Iterables, that Observables can be constructed around to wrap) |
| 15:07 | <annevk> | Dominic Farolino: define ObservableInit as a union of Observable and whatever syntax we have for async iterables (maybe needs to be added?) and make people use that? |
| 15:07 | <annevk> | Dominic Farolino: Promise is an ES type and therefore gets its own to-and-from ES conversion, but you don't have that if you define an interface |
| 15:11 | <Dominic Farolino> | Yeah it's the latter part of "and whatever syntax we have for async iterables" that I'm stuck on. We of course have syntax to make an interface async iterable, but I'm not sure that's usable from within a union... perhaps it does need to be added though idk |
| 15:11 | <Dominic Farolino> | (Same goes for normal iterable I think) |
| 15:16 | <Dominic Farolino> | (Or no, I guess maybe sequence<T> can be used for iterable) |
| 15:41 | <annevk> | Dominic Farolino: yeah, you want async sequence<T> or some such |
| 23:08 | <Domenic> | Dominic Farolino: I think you need object or any with manual steps. In particular, overloading on promises is basically impossible in Web IDL by design. And this would be the second method on the platform to consume async iterators, so you'd need to add something to Web IDL to support that, which I'm not sure is worth it. |
| 23:08 | <Domenic> | Oh, but, if this is just for Observable + async iterable overloads, then maybe that's worth doing |
| 23:08 | <Domenic> | I thought this was just for Observable.from which is very special. |