There are cases, for instance when reading from JSON or reading from EXCEL, or converting iterables to DataFrames containing exceptions where columns containing multiple types will be created.
Currently, DataFrame tries to find the lowest common ancestor of the two types, just like Kotlin's type system, which in many cases (such as for Double+String) results in Serializable or Comparable<*> (or Any).
In such cases, it might be beneficial to have a simple union-type wrapper so people can more easily handle both types individually or convert one of the two types to the other manually.
We could introduce a 2-type wrapper (or 3-type, n-type, but I'd rather not) with a set of extension functions (on ValueColumn<UnionType<A, B>>) and proper type-displaying to make it easier for our users. Potentially we can also investigate how other libraries handle these cases.
There are cases, for instance when reading from JSON or reading from EXCEL, or converting iterables to DataFrames containing exceptions where columns containing multiple types will be created.
Currently, DataFrame tries to find the lowest common ancestor of the two types, just like Kotlin's type system, which in many cases (such as for Double+String) results in
SerializableorComparable<*>(orAny).In such cases, it might be beneficial to have a simple union-type wrapper so people can more easily handle both types individually or convert one of the two types to the other manually.
We could introduce a 2-type wrapper (or 3-type, n-type, but I'd rather not) with a set of extension functions (on
ValueColumn<UnionType<A, B>>) and proper type-displaying to make it easier for our users. Potentially we can also investigate how other libraries handle these cases.