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
Most likely in last statement data field was expected to be an instance of Y instead of X, although given that {y: 2} can be read both as X and Y it was interpreted as a first type in the union X. While this is bad (see #2) it does not seem to be a common issue in my experience.
What happens far more often in my experience is that new type is defined which supposed to be added to a type union (but for whatever reasons it was not added to type union):
Now surprise and a problem is far worse in this case, as passed data field had a type but it got casted to a completely different type. There is also no simple way to avoid or spot this issue.
The text was updated successfully, but these errors were encountered:
I think it would make sense to generate a type identifier field for every record type that is going to be included with each instance. That would have several benefits:
This will also work for union types which is currently painful.
It may enable passing typed records between web workers without loosing type information, although it is unclear if they will be at all useful given that same types won't be available in the worker context.
We could use that to prevent type casting for type unions although without also doing Reconsider duck typing records #2 we would make type union fields odd.
At the moment if you define types with a following signatures:
Then type union interprets
data
value not always as one would expected:Most likely in last statement
data
field was expected to be an instance ofY
instead ofX
, although given that{y: 2}
can be read both asX
andY
it was interpreted as a first type in the unionX
. While this is bad (see #2) it does not seem to be a common issue in my experience.What happens far more often in my experience is that new type is defined which supposed to be added to a type union (but for whatever reasons it was not added to type union):
Now surprise and a problem is far worse in this case, as passed
data
field had a type but it got casted to a completely different type. There is also no simple way to avoid or spot this issue.The text was updated successfully, but these errors were encountered: