Update GC-05-16.md #1279
Update GC-05-16.md #1279
Conversation
Co-authored-by: Andreas Rossberg <[email protected]>
|
Thanks for the edits, @rossberg! |
gc/2023/GC-05-16.md
Outdated
|
|
||
| CW: Who do you imagine will use this as this first choice? | ||
|
|
||
| JX: Developers for LT(???). In the browser, WebAssembly can be some part of the project, if not the whole project. This is more flexible than the current solution. |
There was a problem hiding this comment.
I think 'LT' was actually IoT, but I don't remember how that lead to the next sentence. @xujuntwt95329 if you remember, fell free to suggest edits.
There was a problem hiding this comment.
Thanks @penzn , yes the 'LT' was IoT (Internet of Things), I have submitted a comment
Co-authored-by: Xu Jun <[email protected]>
|
|
||
| RH: I would guess it would be in that case. but I’m sure we could put the type information in that shape so it would be really fast. Right now it’s not, so we’d need a reason to do the work like that. There might be extra metadata costs too. | ||
|
|
||
| AR: This is a form of reflection right? It’s about putting reflection into core wasm. As you might guess, I’m not a big fan of that idea, it seems to be something that should be handled at a higher level than the basic asm instruction set. |
There was a problem hiding this comment.
@rossberg Sorry for missing this question in the meeting, a quick reply here:
- I think the proposed opcode
struct.get/set_indirectis not related to reflection, it's all about getting field index from operand rather than immediate - The idea of
interface description tablemay be something like reflection, but that's not what we want to bring to the core wasm spec, it's just a feasible usage of the proposed opcode
I'll prepare an issue in WebAssembly/gc repo and list some benefits as well as impacts of this opcode for further discussion.
BTW, thanks for your professional questions and suggestions in the meeting, which let me realize there are more things to be considered for the type system
There was a problem hiding this comment.
@xujuntwt95329, since these operations have to inspect and dispatch on (the structure of) the runtime type of the object, they represent a form of type reflection. They would be the Wasm equivalent to struct.getClass().getField(x).get/set(struct), the only difference being that x is numeric, not a string, because fields are accessed by number in Wasm. This idea further assumes that every heap object carries sufficient runtime information to perform such reflection, which is not an assumption I'd like to build into Wasm itself.
There was a problem hiding this comment.
@rossberg Sorry for the late reply because I didn't notice the update on this thread. Since this PR has been merged, I've created an issue WebAssembly/gc#397 for further discussion
No description provided.