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
In StructArrays one generally needs to figure out a type not from fieldvalues (which ConstructionBase can deal with) but from arrays of field values. For example, starting from the type Pair and the columns [1, 2, 3], ["a", "b", 2], I would like to figure out that the eltype for the resulting StructArray (which should be Pair{Int, Any}). Could ConstructionBase be extended to support something like this?
There is a second issue in this example. In this Pair{Int, Any} scenario, the default constructorof would "lie" about the element type. In other words:
julia>constructorof(Pair{Int, Any})(1, "a") isa Pair{Int, Any}
false
Would it be feasible to add a version of constructorof that respects the type parameters? Ideally, that would also address #58 as well as other problematic types (such as types with inner constructors).
The text was updated successfully, but these errors were encountered:
starting from the type Pair and the columns [1, 2, 3], ["a", "b", 2], I would like to figure out that the eltype for the resulting StructArray (which should be Pair{Int, Any}). Could ConstructionBase be extended to support something like this?
How is this related to ConstructionBase or JuliaArrays/StructArrays.jl#241? I don't see any type computations in ConstructionBase now, only construction/modification of instances. That PR also doesn't touch StructArrays eltype computations at all.
Would it be feasible to add a version of constructorof that respects the type parameters?
That's basically just the type itself, unless it defines an inner constructor that doesn't just take its fields. A major point of constructorof is that it can construct an object with different field types, depending on the values.
How is this related to ConstructionBase or JuliaArrays/StructArrays.jl#241? I don't see any type computations in ConstructionBase now, only construction/modification of instances. That PR also doesn't touch StructArrays eltype computations at all.
At the moment it isn't, but I was wondering whether one could have a deeper integration than the one in JuliaArrays/StructArrays.jl#241, where the bypass_constructor hack (as well as the complex promotion mechanisms) in StructArrays were no longer needed.
Naturally, I understand that it could be outside the scope of ConstructionBase.
This continues some of the discussion in #53, esp. #53 (comment). See also JuliaArrays/StructArrays.jl#241 for a PR to use this package in StructArrays.
In StructArrays one generally needs to figure out a type not from fieldvalues (which ConstructionBase can deal with) but from arrays of field values. For example, starting from the type
Pair
and the columns[1, 2, 3]
,["a", "b", 2]
, I would like to figure out that theeltype
for the resultingStructArray
(which should bePair{Int, Any}
). Could ConstructionBase be extended to support something like this?There is a second issue in this example. In this
Pair{Int, Any}
scenario, the defaultconstructorof
would "lie" about the element type. In other words:Would it be feasible to add a version of
constructorof
that respects the type parameters? Ideally, that would also address #58 as well as other problematic types (such as types with inner constructors).The text was updated successfully, but these errors were encountered: