Skip to content

Discussion points

Hannes Hauswedell edited this page Jan 7, 2022 · 7 revisions

A list of things we should discuss before a 1.0 release (create individual pages with details if more than a paragraph is needed):

  1. Should all bio::field enum entries be distinct for simplicity?
  2. "Deep records":
  • Shallow records are default and recommended.
  • Deep records are required sometimes, e.g. in combination with `views::async_input_buffer
  • Currently, one can select deep records via template parameter and the options. This means all formats need to implement it (not that much work actually) and that the options and dynamic_type are more complicated (a little annoying).
  • An alternative design would be to have the formats always output shallow records and offer a generic .make_deep_copy() on the record that returns a self-contained record (this would automatically turn views into vectors...).
  • PRO: the overall design becomes easier to understand; a little less work for format input handlers
  • CON: you cannot specify the specific "deep" types anymore, the record always picks e.g. vector for views; certain optimisations are no longer possible (e.g. deep FASTA reading into std::string can currently avoid a copy by swapping buffers with output strings; this wouldn't be possible in the changed design)
  1. Should all concepts that constrain public interfaces be public? Especially the field_types have lots of requirements. I am afraid this will clutter the documentation significantly.
  2. What happens when a writer receives no record?
  • Currently, nothing happens. But it should write the header to create a valid "empty" file. → the destructor should write the header.
  • What happens when there is no header, because e.g. you stream reader | std::views::filter(foo) | writer; and the filter removes all records? → The assignment/pipe operator should "unpeel" the input range and try to find out if the most-underlying range is a reader and if yes, get that that reader's header and set it.
  1. Do we want to gracefully accept char const * as a string type? I am trying to do this everywhere, but it is a real hassle, because the type is not a range.
Clone this wiki locally