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 > > >
