[gt-users] New feature announcement

[Gordon Gremme]

>> on a sorta related question:
>> should a FeatureStream yield FeatureNodes? currently, it's
>> GenomeNodes.
>
> Not really. All streams generically work on GenomeNodes. Of course,
> internally they are free to handle only the node types they are
> interested in. For example, RegionNodes which pass through a
> FeatureStream are left untouched by the stream itself (as its sole
> function is to collect feature subtrees in a FeatureIndex), but at the
> end of a stream chain they may be wanted. So pulling things through a
> stream should never change the type.

Correct.


> However, I have not yet found a way to 'downcast' an object in a base
> class to a derived class in Python. I do not have much experience with
> Python idioms, after all. One could introduce a 'to_feature_node' method
> to the GenomeNode class, which checks on the C side whether an object
> can be safely cast to a FeatureNode or not and would return a new
> FeatureNode wrapper object if possible. This would require exposing the
> gt_feature_node_try_cast() C function, which is not in the API right now.
> Gordon, do you see a way around this or have a better idea?

I think adding gt_feature_node_try_cast() (or rather
gt_genome_node_try_cast()) to the C API is a good solution to allow
downcasts.
Using it is the best way, if you want to process only one
implementation of the GenomeNode interface  (most commonly the
FeatureNode class). If one wants to process multiple implementations
of the GenomeNode interface, a full-fledged NodeVisitor implementation
is the cleaner solution.

I don't like adding a 'to_feature_node' method to the GenomeNode class, though.
GenomeNode is an interface and shouldn't know anything about it's implementors.
I think it is better to add such functionality to the implementing
class, at it was done with gt_feature_node_try_cast() on the C side.


> P.S. I have your transparent background feature ready. It is in my
> 'brentp' branch -- Gordon, can you pull that into the master? I had to
> remove the @cachedproperty from FeatureNode.get_type() because
> gn.get_type() could not longer be called as a function this way. I
> changed that, if it's ok.

I pulled the 'brentp' branch into the master. Thanks to both of you!

Gordon