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
As ZigSelf's capabilities grow, some issues with using it arises. For starters, there is no good way to declare where an object belongs, i.e. the slot it should be reachable at. In addition, there is no way to give objects their own representation that could be printed because this would not work with traits objects which don't have the slots that a printing method would expect.
Solution
Have ObjectAnnotation and SlotAnnotation object types which would have pre-defined slots for storing each property that we would expect. Each object map and slot would hold a reference to their own annotation object. This would make integrating with the existing VM easy, but could potentially be heavier (because objects and slots with no annotations still have to hold a reference to an annotation object). This could be alleviated by making annotation objects immutable, and starting out objects and slots with a known empty slot.
These objects would need syntax or primitives to instantiate them in order to be filed out.
Potential Problems
If we ever decide to add other annotations after the snapshot format is stabilized, we would be unable to read older snapshots (although this is unlikely in practice).
While the annotations are defined in the VM, they are facilitated by the programming environment; is it right to introduce values specific to the programming environment into the base VM?
The text was updated successfully, but these errors were encountered:
Problem
As ZigSelf's capabilities grow, some issues with using it arises. For starters, there is no good way to declare where an object belongs, i.e. the slot it should be reachable at. In addition, there is no way to give objects their own representation that could be printed because this would not work with traits objects which don't have the slots that a printing method would expect.
Solution
Have
ObjectAnnotation
andSlotAnnotation
object types which would have pre-defined slots for storing each property that we would expect. Each object map and slot would hold a reference to their own annotation object. This would make integrating with the existing VM easy, but could potentially be heavier (because objects and slots with no annotations still have to hold a reference to an annotation object). This could be alleviated by making annotation objects immutable, and starting out objects and slots with a known empty slot.These objects would need syntax or primitives to instantiate them in order to be filed out.
Potential Problems
The text was updated successfully, but these errors were encountered: