1. Objects say you are a melee fighter, and a melee fighter is defined as having X, Y, Z
2. Databases instead say you exist, and if you have X, Y, Z then you can be called a melee fighter.
Thus to transform an entity from one type to another (melee fighter to ranged fighter), you simply need to remove the properties associated with melee fighter and add the properties associated with ranged fighter — and the fact that it is one or another is derived from whatever property it is left with.
And then of course to say someone is both a melee and ranged fighter, then you just need to add the properties of both — being A vs B is not by definition, it’s derived from the properties you have
A rock can be viewed as a chair if it meets sufficient parameters for sitting; it can be viewed as a weapon just the same. These aren’t inherent to the act of being a rock, but rather derived from the composition of the rock
This works, but the result of the query (starting from an object id) varies. What can a static type system do under these circumstances? It seems like it might as well be a dynamic field access?
The result of a database query may have an immutable type, but it can also become stale, like an invalid cache entry. That's a possible bug. Perhaps there's some trick that would allow us to treat a live object as unchanging, with a fixed type and shape, but only within a limited scope in which we can prove it won't mutate?
For example, in a single-threaded language, it seems like we should be able to do a runtime check to get a more specific type and use it until the next await. The runtime check only needs to be done once in that scope.
Comments
I like to view it as:
1. Objects say you are a melee fighter, and a melee fighter is defined as having X, Y, Z
2. Databases instead say you exist, and if you have X, Y, Z then you can be called a melee fighter.
Thus to transform an entity from one type to another (melee fighter to ranged fighter), you simply need to remove the properties associated with melee fighter and add the properties associated with ranged fighter — and the fact that it is one or another is derived from whatever property it is left with.
And then of course to say someone is both a melee and ranged fighter, then you just need to add the properties of both — being A vs B is not by definition, it’s derived from the properties you have
A rock can be viewed as a chair if it meets sufficient parameters for sitting; it can be viewed as a weapon just the same. These aren’t inherent to the act of being a rock, but rather derived from the composition of the rock
This works, but the result of the query (starting from an object id) varies. What can a static type system do under these circumstances? It seems like it might as well be a dynamic field access?
The result of a database query may have an immutable type, but it can also become stale, like an invalid cache entry. That's a possible bug. Perhaps there's some trick that would allow us to treat a live object as unchanging, with a fixed type and shape, but only within a limited scope in which we can prove it won't mutate?
For example, in a single-threaded language, it seems like we should be able to do a runtime check to get a more specific type and use it until the next await. The runtime check only needs to be done once in that scope.