Hi, I was wondering what's the common attitude towards using Optional in APIs, and what naming pattern should we use. As an example, I dislike calling if (entry.getMetadata() != null && entry.getMetadata().version() != null) { foo.use(entry.getMetadata().version()) } where I could just do entry.metadata().flatMap(Metadata::optionalVersion).ifPresent(foo::use) Here I have proposed metadata() method returning Optional<Metadata> (regular getter method is called getMetadata()) and annoying optionalVersion() as version() is the regular getter. Shall we adopt some common stance (use/don't use/use at developer's discretion) and naming conventions? Is it acceptable to start adding default Optional<Foo> foo() { Optional.ofNullable(getFoo()); } whenever we feel the urge to chain Optionals? Radim -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I secretly hope that all these allocations would be inlined and eliminated. If we find out that it really allocates the objects (from JFR's allocation stats), it's a reason to rewrite that piece of code to the dull optionless version. TBH I am rather afraid that the JVM will allocate the consumer which will need some captured variables. Maybe I trust C2 compiler too much, believing that if the handler isn't too big, it will generate similar instructions with nicer source code :-/ R. On 03/30/2017 11:08 PM, Sanne Grinovero wrote: > I'm for "at discretion" and "avoid if not really needed" : not cool to > allocate objects for no reason. > > On 30 Mar 2017 16:57, "Radim Vansa" <rvansa(a)redhat.com > <mailto:rvansa@redhat.com>> wrote: > > Hi, > > I was wondering what's the common attitude towards using Optional in > APIs, and what naming pattern should we use. As an example, I dislike > calling > > if (entry.getMetadata() != null && entry.getMetadata().version() > != null) { > foo.use(entry.getMetadata().version()) > } > > where I could just do > > entry.metadata().flatMap(Metadata::optionalVersion).ifPresent(foo::use) > > Here I have proposed metadata() method returning Optional<Metadata> > (regular getter method is called getMetadata()) and annoying > optionalVersion() as version() is the regular getter. > > Shall we adopt some common stance (use/don't use/use at developer's > discretion) and naming conventions? Is it acceptable to start adding > > default Optional<Foo> foo() { Optional.ofNullable(getFoo()); } > > whenever we feel the urge to chain Optionals? > > Radim > > -- > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

I was about to say the same: in the typical use case of returning an optional and using it immediately it would probably end up on the stack anyway... Tristan On 31/03/2017 09:57, Radim Vansa wrote: > I secretly hope that all these allocations would be inlined and > eliminated. If we find out that it really allocates the objects (from > JFR's allocation stats), it's a reason to rewrite that piece of code to > the dull optionless version. > TBH I am rather afraid that the JVM will allocate the consumer which > will need some captured variables. Maybe I trust C2 compiler too much, > believing that if the handler isn't too big, it will generate similar > instructions with nicer source code :-/ > > R. > > > On 03/30/2017 11:08 PM, Sanne Grinovero wrote: >> I'm for "at discretion" and "avoid if not really needed" : not cool to >> allocate objects for no reason. >> >> On 30 Mar 2017 16:57, "Radim Vansa" <rvansa(a)redhat.com >> <mailto:rvansa@redhat.com>> wrote: >> >> Hi, >> >> I was wondering what's the common attitude towards using Optional in >> APIs, and what naming pattern should we use. As an example, I dislike >> calling >> >> if (entry.getMetadata() != null && entry.getMetadata().version() >> != null) { >> foo.use(entry.getMetadata().version()) >> } >> >> where I could just do >> >> entry.metadata().flatMap(Metadata::optionalVersion).ifPresent(foo::use) >> >> Here I have proposed metadata() method returning Optional<Metadata> >> (regular getter method is called getMetadata()) and annoying >> optionalVersion() as version() is the regular getter. >> >> Shall we adopt some common stance (use/don't use/use at developer's >> discretion) and naming conventions? Is it acceptable to start adding >> >> default Optional<Foo> foo() { Optional.ofNullable(getFoo()); } >> >> whenever we feel the urge to chain Optionals? >> >> Radim >> >> -- >> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org <mailto: infinispan-dev(a)lists.jboss.org&gt; >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev