JuliaData / JuliaData/StructTypes.jl

Combining abstract types and parametric types?

Open
#76 0 comments 0 reactions 0 assignees View on GitHub

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 type name for each concrete version of Child2{N} you expect to be possible: (child1=Child1, child2U8=Child2{UInt8}, child2I32=Child2{Int32}, ...)
  • Use UnorderedStruct or OrderedStruct instead of Mutable, 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.