[infinispan-dev] Strategy to adopting Optional in APIs

[Tristan Tarrant]

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