[infinispan-dev] Strategy to adopting Optional in APIs

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Strategy to adopting Optional in APIs

Radim Vansa
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 <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Sanne Grinovero-3
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" <[hidden email]> 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 <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Radim Vansa
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" <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Tristan Tarrant-2
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" <[hidden email]
>> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>>      JBoss Performance Team
>>
>>      _______________________________________________
>>      infinispan-dev mailing list
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Dan Berindei
Maybe yes, maybe not... in my experience escape analysis is very
fickle, e.g. it's very easy for a method to become big enough after
inlining that escape analysis is not performed at all.

Dan

On Fri, Mar 31, 2017 at 10:59 AM, Tristan Tarrant <[hidden email]> 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" <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>>>      JBoss Performance Team
>>>
>>>      _______________________________________________
>>>      infinispan-dev mailing list
>>>      [hidden email] <mailto:[hidden email]>
>>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Sebastian Laskawiec
In reply to this post by Tristan Tarrant-2
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 <[hidden email]> 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" <[hidden email]
>> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>>      JBoss Performance Team
>>
>>      _______________________________________________
>>      infinispan-dev mailing list
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>      <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...