| 09:50 | <jgraham> | I have a spec algorithm that takes a javascript object of arbitary type and runs some type-specific steps. How is one supposed to switch-on-type in a spec these days? |
| 09:51 | <annevk> | jgraham: is it converted to an IDL object? |
| 09:52 | <jgraham> | No, although maybe it can be? It can also be a primitive type if that makes a difference |
| 09:52 | <annevk> | jgraham: has it passed through IDL is the question I guess |
| 09:53 | <annevk> | but generally "if _x_ is a Foo" |
| 09:53 | <annevk> | or switching on _x_: <dl><dt>Foo<dd>... |
| 09:53 | <jgraham> | It hasn't passed through IDL; the use case is WebDriver where we want to convert an arbitary object from script into a wire representation |
| 09:55 | <jgraham> | But if I"m allowed to just act as if the type of x is a well defined concept without caring about the mechanics of how js encodes the type, what I have isn't so wrong |
| 09:56 | <annevk> | jgraham: you can use https://heycam.github.io/webidl/#es-platform-objects |
| 09:56 | <annevk> | jgraham: and for serialization you probably want some alignment with HTML's serialization algorithms for ES values |
| 09:58 | <jgraham> | Yeah, maybe |
| 09:59 | <jgraham> | It's definitely going to be different to that because different requirements, but it might make sense to use that to provide a value representation for more types |
| 10:00 | <annevk> | jgraham: HTML's serialization algorithm does do all the formal stuff correctly (or so we like to think) |
| 10:00 | <jgraham> | (the "different requirements" are basically that we pass back a handle that acts a weakref to the object, which doesn't make sense for the HTML case) |
| 10:02 | <jgraham> | (but we also provide a value for types where it makes sense, and only a value for primitives) |
| 10:04 | <jgraham> | (and also because JSON, we can't represent some things that structured serialize can) |
| 10:04 | <jgraham> | Anyway, that's useful thanks |