I like the idea of using Optionals. But I think we would need to enhance all our APIs to use this (to be consistent).
Maybe you could come up with a small proposition of API changes? It might not work correctly (we can just mock them) but I would love to see some examples and "feel" the semantics. On Fri, Mar 31, 2017 at 10:00 AM Tristan Tarrant <ttarr...@redhat.com> wrote: > 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" <rva...@redhat.com > >> <mailto:rva...@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 <rva...@redhat.com <mailto:rva...@redhat.com>> > >> JBoss Performance Team > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@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@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
