Roadmap (near future)

[rasmushenningsson]

Roadmap overview

Here we outline the updates that are coming in VariantCallFormat.jl 0.5.x and 0.6.
It's mainly an effort to update VariantCallFormat.jl to be written in "modern" Julia and to clean up the interface.

0.5.x goals

• No breaking changes (compared to GeneticVariation.jl 0.4).
• Define the public interface of VariantCallFormat.jl. (Since most functions are unexported at the moment, it is currently not clear what is public and what is private.)
• Implement the same methods/interface for VCF and BCF (making it easier for users to write generic code).
• Follow conventions from Base Julia.
• Support getproperty for Record. E.g. record.pos, record.filter, record.info[key]. This is an easy, understandable interface and a nice way to get around name clash issues with Base.
• Add deprecations in preparation for 0.6.

0.6 goals

• Improve type stability for info and genotype.
• Breaking changes needed to unify VCF/BCF interface.
• Minimize and document breaking changes.

Specific changes planned

Header interface

• Public interface: Add metainfo(header) and sampleids(header)
• Do not wrap Base methods without reason - deprecate eltype, length, iterate, pushfirst!, push!. (Use e.g. push!(metainfo(header)) instead.)
• Deprecate findall(header,tag) and replace with metainfo(header,tag).

VCF/BCF records

• Add AbstractRecord.
• Add getproperty support.
• VCF/BCF methods should take the same argument types and use the same return types (as far as possible).
• Implement missing BCF methods such as hasqual(), hasinfo()
• Unify missing data handling. E.g. hasqual(), qual() should behave identically for VCF/BCF.

Type stability

Achieving type stability for some VCF/BCF fields is tricky, because the data types are encoded in the file and cannot be known at compile-time. However, often the user knows. Consider the INFO field DP that must be an integer, by specifying the desired type in the call, the user code will be type stable and the user will get a good error message if the type is wrong (malformed file). Example:

record.info(Int,"DP")

As a bonus, this makes it easy to handle both VCF/BCF with generic, type-stable code, even though the field is saved as a String in VCF and as (vector of) int8_t/int16_t/int32_t/float/char in BCF.

If the user doesn't specify the type, the VCF/BCF header will used to determine the return type (when needed).

[rasmushenningsson]

I never found the time to push this forward. Closing issue.