[infinispan-dev] Strategy to adopting Optional in APIs

[Sebastian Laskawiec]

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 <ttarrant at 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" <rvansa at redhat.com
> >> <mailto:rvansa at 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 at redhat.com <mailto:rvansa at redhat.com>>
> >>      JBoss Performance Team
> >>
> >>      _______________________________________________
> >>      infinispan-dev mailing list
> >>      infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170331/65d78a81/attachment-0001.html