[gt-users] one more question (sorry)

[Gordon Gremme]

> However, to discuss your worries, isn't a "FeatureStream" already assuming that the contents are actually "FeatureNodes" and not simply the upper class objects "GenomeNodes"?   Why shouln't  FeatureStream.next_tree() guarantee that it returns Features rather than GenomeNodes?
>
> Are there any instances where a FeatureStream would encounter a GenomeNode that cannot be cast as a FeatureNode?  (I can't think of any when parsing GFF3 files).  I guess that it happens like this as the FeatureStream is inheriting the .next_tree() method directly from the GenomeStream interface, right?

Some clarification: GenomeNode is the interface and it has currently
four implementations: CommentNode, FeatureNode, RegionNode and
SequenceNode. Objects of all four implementations could be created
when a GFF3 file is parsed. CommentNodes correspond to comment lines
(starting with a single #). FeatureNodes are the most common ones and
correspond to the regular GFF3 lines (with children attaches to their
parents). RegionNodes correspond to ##sequence-region lines and
SequenceNodes correspond to embedded Fasta files. Therefore, a
NodeStream always has to handle the generic GenomeNodes and cannot
assume that only a certain implementation will pass through it.

Gordon