3 ms·
I initially didn't like the high level idea, but I warmed up to it. My only concern is that the constructor isn't guaranteed to define the same fields with the
by bastawhiz 2y ago
I initially didn't like the high level idea, but I warmed up to it. My only concern is that the constructor isn't guaranteed to define the same fields with the same types, which kind of defeats the point.
I'd improve this proposal in two ways:
1. Explicitly define the layout with types. It's new syntax already, you can be spicy here.
2. Define a way for structs to be directly read into and out of ArrayBuffers. Fixed layout memory and serialization go hand in hand. Obviously a lot of unanswered questions here but that's the point of the process.
The unsafe block stuff, frankly, seems like it should be part of a separate proposal.
- jtolmar 2y agoI agree; the point of a struct type would be to allow a compact memory representation, and you're not going to get it if your constructor can do if(someArg) { a = 1; } else { a = 1; b = 2; }. You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes. I don't think a way to read into and out of ArrayBuffers is possible, since these can have pointers in them. I think it needs a StructArray class instead, so there's a way to actually make a compact memory array out of all of this.
- bastawhiz 2y ago> You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes. Arguably that's worse than what the runtime is able to do today already with hidden classes. > I don't think a way to read into and out of ArrayBuffers is possible If you know all the types and only allow structs and primitives, you could use relative pointers to encode the 2nd+ references to structs that appear more than once in the encoded object. You'd need a StructArray for efficient arrays, but a linked list would encode pretty compactly. But you're very right.