edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale LaBossiere (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QUARKS-229) Streams and tuple type hierarchies - TStream.cast()?
Date Wed, 13 Jul 2016 15:56:20 GMT

    [ https://issues.apache.org/jira/browse/QUARKS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15375249#comment-15375249

Dale LaBossiere commented on QUARKS-229:

djd:  Any reason why the original streams were just not declared with the base type?
dlaboss: Yes. Imagine there are both base-type analytics and derived-type analytics.

djd:Would it help if union signature was changed to:
    TStream<T> union(TStream<? extends T> other);

dlaboss: It wouldn’t directly/completely.  i.e.,  logically one wants:
	TStream<Base> sB = sDerived1.union(sDerived2);  // but Derived2 derives from Base not

With only that union change, one still has to:
	TStream<Base> sB = sDerived1  ???  some cast-ish thing is needed
	sB = sB.union(sDerived2);

With some-cast there’s no need to change union, though that might still be useful.

By “larger” [more than union] I was thinking of something like someone already wrote doBaseAnalytics(TStream<Base>).
Shame on them for not enabling future reuse by writing doBaseAnalytics(TStream<? extends
Imagine at the time it was written there weren’t any derived classes / it wasn’t imagined
there would be any.
Some cast-ish thing addresses that case too.

Related, a collection of Base oriented “functions" may have been written.
Those and the methods that use them would have to be adjusted too?  Function<? extends
Base, String> baseKeyFn
(maybe that’s related to the publish() you mentioned. e.g., KafkaPublisher.publish())

> Streams and tuple type hierarchies - TStream.cast()?
> ----------------------------------------------------
>                 Key: QUARKS-229
>                 URL: https://issues.apache.org/jira/browse/QUARKS-229
>             Project: Quarks
>          Issue Type: Improvement
>            Reporter: Dale LaBossiere
>            Priority: Minor
> In a real use case there were two different types of sensors that had
> a common interface/info to be analyzed.  It took a bit to figure out how to
> deal with this.  It certainly wasn't convenient.
> Imagine the tuple type hierarchy:
> class Base {};
> class Derived1 extends Base {};
> TStream<Derived1> sDerived1 = ...;  // ingest
> class Derived2 extends Base {};
> TStream<Derived2> sDerived2 = ...;  // ingest
> TStream<Base> sBase = sDerived1.union( sDerived2 );
> doAnalytics( sBase );
> The union() gets a compilation error because TStream<Derived*> doesn't extend TStream<Base>.
 Std java generics stuff.    A straightforward cast doesn't work; it requires a bit more convoluted
> [I'll capture the essence of a thread on the dev list for this below]

This message was sent by Atlassian JIRA

View raw message