To make it clear, it’s outlined by Damian, I just copy pasted what he told me in person :)
Eno > On Jun 21, 2017, at 4:40 PM, Bill Bejeck <bbej...@gmail.com> wrote: > > +1 for the approach outlined above by Eno. > > On Wed, Jun 21, 2017 at 11:28 AM, Damian Guy <damian....@gmail.com> wrote: > >> Thanks Eno. >> >> Yes i agree. We could apply this same approach to most of the operations >> where we have multiple overloads, i.e., we have a single method for each >> operation that takes the required parameters and everything else is >> specified as you have done above. >> >> On Wed, 21 Jun 2017 at 16:24 Eno Thereska <eno.there...@gmail.com> wrote: >> >>> (cc’ing user-list too) >>> >>> Given that we already have StateStoreSuppliers that are configurable >> using >>> the fluent-like API, probably it’s worth discussing the other examples >> with >>> joins and serdes first since those have many overloads and are in need of >>> some TLC. >>> >>> So following your example, I guess you’d have something like: >>> .join() >>> .withKeySerdes(…) >>> .withValueSerdes(…) >>> .withJoinType(“outer”) >>> >>> etc? >>> >>> I like the approach since it still remains declarative and it’d reduce >> the >>> number of overloads by quite a bit. >>> >>> Eno >>> >>>> On Jun 21, 2017, at 3:37 PM, Damian Guy <damian....@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I'd like to get a discussion going around some of the API choices we've >>>> made in the DLS. In particular those that relate to stateful operations >>>> (though this could expand). >>>> As it stands we lean heavily on overloaded methods in the API, i.e, >> there >>>> are 9 overloads for KGroupedStream.count(..)! It is becoming noisy and >> i >>>> feel it is only going to get worse as we add more optional params. In >>>> particular we've had some requests to be able to turn caching off, or >>>> change log configs, on a per operator basis (note this can be done now >>> if >>>> you pass in a StateStoreSupplier, but this can be a bit cumbersome). >>>> >>>> So this is a bit of an open question. How can we change the DSL >> overloads >>>> so that it flows, is simple to use and understand, and is easily >> extended >>>> in the future? >>>> >>>> One option would be to use a fluent API approach for providing the >>> optional >>>> params, so something like this: >>>> >>>> groupedStream.count() >>>> .withStoreName("name") >>>> .withCachingEnabled(false) >>>> .withLoggingEnabled(config) >>>> .table() >>>> >>>> >>>> >>>> Another option would be to provide a Builder to the count method, so it >>>> would look something like this: >>>> groupedStream.count(new >>>> CountBuilder("storeName").withCachingEnabled(false).build()) >>>> >>>> Another option is to say: Hey we don't need this, what are you on >> about! >>>> >>>> The above has focussed on state store related overloads, but the same >>> ideas >>>> could be applied to joins etc, where we presently have many join >> methods >>>> and many overloads. >>>> >>>> Anyway, i look forward to hearing your opinions. >>>> >>>> Thanks, >>>> Damian >>> >>> >>