designing kafka code for stable extensibility is a worthy and noble cause. however, seeing as there are no such derivatives out in the wild yet i think investing the effort right now is a bit premature from kafka's pov. I think its enough simply not to purposefully prevent such extensions.
On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <ism...@juma.me.uk> wrote: > On Sat, Nov 26, 2016 at 11:08 PM, radai <radai.rosenbl...@gmail.com> > wrote: > > > "compatibility guarantees that are expected by people who subclass these > > classes" > > > > sorry if this is not the best thread for this discussion, but I just > wanted > > to pop in and say that since any subclassing of these will obviously not > be > > done within the kafka codebase - what guarantees are needed? > > > > I elaborated a little in my other message in this thread. A simple and > somewhat contrived example: `ConsumerRecord.toString` calls the `topic` > method. Someone overrides the `topic` method and it all works as expected. > In a subsequent release, we change `toString` to use the field directly > (like it's done for other fields like `key` and `value`) and it will break > `toString` for this user. One may wonder: why would one override a method > like `topic`? That is a good question, but part of the exercise is deciding > how we approach these issues. We could make the methods final and eliminate > the possibility, we could document it so that users can choose to do weird > things if they want, etc. > > Another thing that is usually good to think about is the expectation for > `equals` and `hashCode`. What if subclasses implement them to have value > semantics instead of identity semantics. Is that OK or would it break > things? > > Designing for implementation inheritance is generally complex although for > simple "record" like classes, it can be easier by following a few > guidelines. > > Ismael >
