kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Aerts <steven.ae...@gmail.com>
Subject Re: [DISCUSS] KIP-218: Make KafkaFuture.Function java 8 lambda compatible
Date Sun, 21 Jan 2018 10:22:48 GMT
Xavier, Ismael,


I think I updated everything.
The KIP has been lined up with the latest version of the PR, it is free for
everyone to be reviewed.

Thanks for your feedback,


   Steven



Op do 18 jan. 2018 om 13:10 schreef Steven Aerts <steven.aerts@gmail.com>:

> Ok, will cook something up by the end of the weekend.
>
> Op wo 17 jan. 2018 om 18:36 schreef Xavier Léauté <xavier@confluent.io>:
>
>> Hi Steven, do you think you'll get a chance to address the points Ismael
>> made? It'd be great to get this change into 1.1.
>>
>> Thanks!
>> Xavier
>>
>> On Tue, Dec 19, 2017 at 12:20 PM Ismael Juma <ismael@juma.me.uk> wrote:
>>
>> > Hi Steven,
>> >
>> > As a general rule, we don't freeze KIPs after the vote passes. It's
>> > reasonably common for things to come up during code review, for
>> example. If
>> > we think of improvements, we shouldn't refrain from doing them because
>> of
>> > of the vote. If we do minor changes after the KIP passes, we usually
>> send a
>> > follow-up to the vote thread and assume it's all good if no objections
>> are
>> > raised. Only significant changes require a vote from scratch (this
>> tends to
>> > be rare). More inline.
>> >
>> > On Tue, Dec 19, 2017 at 7:58 PM, Steven Aerts <steven.aerts@gmail.com>
>> > wrote:
>> > >
>> > > > 1. The KIP seems to rely on the pull request for some of the
>> details of
>> > > the
>> > > > proposal. Generally, the KIP should stand on its own.
>> > >
>> > > Looking back at what I wrote in the KIP, I agree that its style is too
>> > > descriptive
>> > > and relies too much on the content of the PR.
>> > > I will keep it in mind, and try to do better next time.  But as the
>> > > voting is over I
>> > > assume I better not alter it any more.
>> > >
>> >
>> > I think we should fix this. At a minimum, the public interfaces section
>> > should include the signature of interfaces and methods being added (as I
>> > said before).
>> >
>> > > 2. Do we really need to deprecate `Function`? This will add build
>> noise
>> > to
>> > > > any library that builds with 1.1+ but also wants to support 0.11 and
>> > 1.0.
>> > >
>> > > No we don't.  It is all a matter of how fast we can and want an api
>> > tagged
>> > > with
>> > > @Evolving, to evolve.
>> > > As we know, that it will evolve again when KIP-118 (dropping java 7)
>> is
>> > > implemented.
>> > >
>> >
>> > For widely used APIs like the AdminClient, it's better to be
>> conservative.
>> > We can look at deprecations once we drop Java 7 so that we do them all
>> at
>> > once.
>> >
>> >
>> > > > 3. `FunctionInterface` is a bit of a clunky name. Due to lambdas,
>> users
>> > > > don't have to type the name themselves, so maybe it's fine as it
>> is. An
>> > > > alternative would be `BaseFunction` or something like that.
>> > >
>> > > I share a little bit your feeling, as the best name for me would just
>> be
>> > > `Function`.  But that one is taken.
>> > >
>> >
>> > Yeah, it's a case of choosing the second best option.
>> >
>> > Ismael
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message