Siyuan, I believe it is important that users can extends the API. At the same time, this capability should not complicate the use of the out of the box API. I believe this can be accomplished with your second option.
I created the following example: http://pastebin.com/ZZ6VpTTP The use of the base API isn't affected, it's just that when using the extended interface the user needs to use an additional assignment or tell the compile the type parameters. I think that's an acceptable solution? Thanks, Thomas On Mon, May 16, 2016 at 11:09 AM, Siyuan Hua <[email protected]> wrote: > Hi guys > The core part of the high-level API is the Stream interface. It includes > some build-in transformations. And We want to make it easily extensible, > but java language has some limitation to prevent us from doing this. > > Here is an example: > > > *interface Stream<T> {* > > * <O> Stream<O> map(Function<T, O> f)* > *}* > > > > *class StreamImpl<T> implement Stream<T> { .....}* > > If you extend your own stream implementation > > *class YourStreamImpl<T> extends StreamImpl {* > > * <O> YourStreamImpl<O> enrich(Function<T, O> f)* > *}* > > > It won't compile if you do > > *new YourStreamImpl<String>().map().enrich()* > Here are some options to solve this problem with some compromise. > 1. Keep this way but developer needs to do type cast > > *((YourStreamImpl<String>)new YourStreamImpl<String>().map()).enrich()* > 2. Change the interface to something below > > *interface Stream<T> {* > * <O, STREAM extends Stream<O>> STREAM map(Function<T, O> f)**}* > then you can do something like this *new YourStreamImpl<String>().<String, > * > > *YourStreamImpl<String>>map().enrich()* > 3. Wipe out the type variable > > *interface Stream {* > * <STREAM extends Stream> STREAM map(Function f)**}* > then you can always do > *new YourStreamImpl().map().enrich* > The problem here is you lose the compile time type checking > > 4. Leave the flexibility to scala API not java. Remember you can extend the > functionality from Function/Operator interface(We will add apex module > support later). > > Please let me know your preference or if you have better idea. > > Thank you, > Siyuan >
