JuliaData / JuliaData/StructTypes.jl
Combining abstract types and parametric types?
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 86
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
Let's say I have a type hierarchy like this:
abstract type Parent end
mutable struct Child1 <: Parent
type # Set to 'child1'
end
mutable struct Child2{N<:Integer} <: Parent
type # Set to 'child2'
i::N
end
StructTypes.StructType(::Type{Parent}) = StructTypes.AbstractType()
StructTypes.StructType(::Type{Child1}) = StructTypes.Mutable()
StructTypes.StructType(::Type{<:Child2}) = StructTypes.Mutable()
StructTypes.subtypekey(::Type{Parent}) = :type
StructTypes.subtypes(::Type{Parent}) = (child1=Child1, child2=Child2)
Currently, afaik, there is no mechanism for StructTypes to serialize/deserialize the value of N, like how it can write the type key for each child.
Current workarounds I can think of:
- Pick a unique
typename for each concrete version ofChild2{N}you expect to be possible:(child1=Child1, child2U8=Child2{UInt8}, child2I32=Child2{Int32}, ...) - Use
UnorderedStructorOrderedStructinstead ofMutable, and let the type parameter be inferred by the constructor.
Would it be feasible to support deserializing type parameters in the same way as the type itself? For example:
struct Child2{N<:Integer} <: Parent
type # Set to 'child2'
int_type::Type # Set to string(N)
i::N
end
StructTypes.parametrickey(::Type{<:Child2}, ::Val{1}) = :int_type
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing StructTypes.StructType, subtypekey, and subtypes entry points described in the issue, then compare them with the proposed parametrickey API. Determine how type-parameter values should be represented and reconstructed, including interaction with abstract subtypes. Done means the behavior and API are specified clearly enough to guide an implementation and its tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100