I guess Scala corrupted my brain because I can't see why ()-> all and ([])-> none is intuitive :)
I would much prefer: empty-> no topics, null -> exception and boolean for "all". Ismael, can you detail how the Optional approach would work in the wire protocol? It sounds good, but I'm unclear on what this would look like on the wire. Gwen On Wed, Mar 30, 2016 at 9:43 AM, Ismael Juma <ism...@juma.me.uk> wrote: > My concern is that this approach is error-prone and a bit magical. It is > possible to do that in the wire protocol while using a safer approach in > the code if people prefer this option (by using a type like `Optional` in > Java). > > Ismael > > On Wed, Mar 30, 2016 at 5:33 PM, Jason Gustafson <ja...@confluent.io> > wrote: > > > Yeah, that actually is intuitive when viewed that way. > > > > -Jason > > > > On Wed, Mar 30, 2016 at 9:25 AM, Dana Powers <dana.pow...@gmail.com> > > wrote: > > > > > Perhaps python has corrupted my brain, but a null arg seems quite clean > > to > > > me: > > > > > > getTopics() -> returns all > > > getTopics([]) -> returns none > > > getTopics([foo, bar]) -> returns foo and bar only > > > > > > -Dana > > > > > > On Wed, Mar 30, 2016 at 9:10 AM, Jason Gustafson <ja...@confluent.io> > > > wrote: > > > > > > > > > > > > > Yes, I think empty should be "no topics" too. However, I would > > suggest > > > > > using a boolean to indicate "all topics" and null should not be > > allowed > > > > (as > > > > > it is now). I think this is a clearer API and it's similar to > > > > > how org.apache.kafka.clients.Metadata works today. > > > > > > > > > > > > +1. Having null imply all is almost as weird as using empty, though > at > > > > least it avoids the most common usage problem. > > > > > > > > -Jason > > > > > >
