You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm failing to see how non-shared structs are different from, say something like this:
structclass Box {x;// Initialized to undefined
#_=void Object.seal(this);// Sealedconstructor(x){this.x =x;}}
Object.freeze(Box);
Object.freeze(Box.prototype);constbox=new Box(123);
box.y =123;// TypeError: Object is non-extensible
box.x =123;// Ok
It's also not very clear to me why would non-shared structs be allowed to have methods. It wouldn't make them much different from classes besides from the internally "fixed layout" thing (sealed).
Personally, I think there are more use cases for structs that resemble factory functions/constructors for "fixed layout" "plain objects". Ideally with no need for an explicit constructor function:
Now shared struct could have the same semantics as non-shared with the only difference of only being allowed to contain primitives to other shared structs:
structclass Box {x=0;y=0;}structshared class Asd {x=0;}const box1 =new Box();// Box { x: 0, y: 0 }const box2 =new Box({x:()=>0});// Box { x: function, y: 0 }const asd1 =new Asd(box1);// Asd { x: 0 } <- x is primitiveconstasd2=new Asd(box2);// Error (x is not shared struct or primitive)
This would - imho - reduce the confusion around non-shared structs vs sealed classes vs shared structs. And the syntax is minimal.
I see structs as a way to define plain-object data structures with a fixed layout (for the engine) that can be passed around from method to method minimizing the changes for de-optimizations. In this proposal shared structs seem to go one step ahead to allow passing whole structs across threads.
I have written a separate proposal here Data Structures: struct (as a way to put my thoughts down). Maybe it's redundant and initially I thought my proposal had a separate goal from this one here but after trying to read and understand more about non-shared structs, maybe we're talking about the same things.
The text was updated successfully, but these errors were encountered:
Hi,
I'm failing to see how non-shared structs are different from, say something like this:
It's also not very clear to me why would non-shared structs be allowed to have methods. It wouldn't make them much different from classes besides from the internally "fixed layout" thing (sealed).
Personally, I think there are more use cases for structs that resemble factory functions/constructors for "fixed layout" "plain objects". Ideally with no need for an explicit constructor function:
Structs can only extends structs makes sense. To clarify, can a class extends a struct? Personally, that would make sense to me.
Now
shared struct
could have the same semantics as non-shared with the only difference of only being allowed to contain primitives to other shared structs:This would - imho - reduce the confusion around non-shared structs vs sealed classes vs shared structs. And the syntax is minimal.
I see structs as a way to define plain-object data structures with a fixed layout (for the engine) that can be passed around from method to method minimizing the changes for de-optimizations. In this proposal shared structs seem to go one step ahead to allow passing whole structs across threads.
I have written a separate proposal here Data Structures: struct (as a way to put my thoughts down). Maybe it's redundant and initially I thought my proposal had a separate goal from this one here but after trying to read and understand more about non-shared structs, maybe we're talking about the same things.
The text was updated successfully, but these errors were encountered: