Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Thanks for taking a look, Boyang! Sure thing. JoinWindows is really just a way to specify how much of a buffer to maintain in order to support the API, namely how much of a timestamp delta should be joinable between the two streams. It’s not quite chopping the input streams up into Windows the

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Hey John, in the Public interface section, you mentioned `Do not add the new interface to JoinWindows, which should not be part of this hierarchy`, could you explain a bit why and what's the plan with JoinWindows? On Tue, Jul 28, 2020 at 12:50 PM Sophie Blee-Goldman wrote: > Awesome, thanks for

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Awesome, thanks for looking into the Window improvements as well! (And I'm sorry I brought this upon you). I hope it's not too painful to get everything in the Windows ecosystem looking good and reasonable, and the benefits are pretty clear. Haven't had a careful look through the POC yet but the p

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Hi Sophie, A quick update: I've pushed a commit to the POC PR that includes the migration of Window to become a data class instead of an abstract class. It's quite a bit of code, but it does look like there is a clean deprecation/migration path. The basic idea is that we drop the "abstract" modif

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Thanks for the reply, Sophie. Yes, I'd neglected to specify that Windows will implement maxSize() by delegating to size(). It's updated now. I'd also neglected to say that I plan to alter both windowBy methods to use the new interface now. Because Windows will implement the new interface, all impl

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Thanks for taking the time to really fill in the background details for this KIP. The Motivation section is very informative. Hopefully this will also serve as a warning against making similar such mistakes in the future :P I notice that the `Window` class that parametrizes EnumerableWindowDefinit

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Thanks Sophie and Boyang for asking for specifics. As far as I can tell, if we were to _remove_ all the non-public-method members from Windows, including any constructors, we are left with effectively an interface. I think this was my plan before. I don't think I realized at the time that it's pos

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Thanks for the KIP John. I share a similar concern with the motivation, it would be good if you could cast light on the actual downside of using a base class vs the interface, is it making the code fragile, or requiring redundant implementation, etc. Boyang On Tue, Jul 21, 2020 at 2:19 PM Sophie

Re: [DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Hey John, Thanks for the KIP. I know this has been bugging you :) That said, I think the KIP is missing some elaboration in the Motivation section. You mention a number of problems we've had and lived with in the past -- could you give an example of one, and how it would be solved by your proposa

[DISCUSS] KIP-645: Replace abstract class Windows with a proper interface

Hello all, I'd like to propose KIP-645, to correct a small API mistake in Streams. Fixing this now allows us to avoid perpetuating the mistake in new work. For example, it will allow us to implement KIP-450 cleanly. The change itself should be seamless for users. Please see https://cwiki.apache.