Hey!
In our past we had a couple of discussions about whether we should or
should not use Optionals [1][2]. The main argument against it was
performance.
On one hand we risk additional object allocation (the Optional itself) and
wrong inlining decisions taken by C2 compiler [3]. On the other hand
Hi Sebastien,
First thing to say, you impress me with all this work ! Thank you very much
!
I've been working with Scala for almost three years, and I really
appreciate the functional code style. This involves the use of Optionals
among other things you mention like map, flapMap etc. Looking at t
Hi Sebastian,
sorry but I think you've been wasting time, I hope it was fun :) This is
not the right methodology to "settle" the matter (unless you want Radim's
eyes to get bloody..).
Any change in such a complex system will only affect the performance
metrics if you're actually addressing the do
I think Sanne's right here, any differences in such large scale test are hard
to decipher.
Also, as mentioned in a previous email, my view on its usage is same as Sanne's:
* Definitely in APIs/SPIs.
* Be gentle with it internals.
Cheers,
--
Galder ZamarreƱo
Infinispan, Red Hat
> On 18 May 2017
Hey!
So I think we have no extreme naysayers to Optional. So let me try to sum
up what we have achieved so:
- In macroscale benchmark based on REST interface using Optionals didn't
lower the performance.
- +1 for using it in public APIs, especially for those using functional
style.
I wouldn't say I'm an extreme naysayer, but I do have 2 issues with
Optional:
1. Performance becomes harder to quantify: the allocations may or may not
be eliminated, and a change in one part of the code may change how
allocations are eliminated in a completely different part of the code.
2. My pe
+1 to Dan's opinion
On Tue, May 23, 2017 at 3:58 PM, Dan Berindei
wrote:
> I wouldn't say I'm an extreme naysayer, but I do have 2 issues with
> Optional:
>
> 1. Performance becomes harder to quantify: the allocations may or may not
> be eliminated, and a change in one part of the code may chang
Dan, I disagree with point 2 where you say "You now have a field that could
be null, Optional.empty(), or Optional.of(something)"
This is the point of optional. You shouldn't have a field that has these 3
possible values, just two of them = Some or None. If the field is mutable,
it should be initi
Actually, I'm an extreme naysayer! I actually voiced concerns so I'm
wondering where your assumption there are no naysayers is coming from... :-)
On 23/05/17 1:54 PM, Sebastian Laskawiec wrote:
> Hey!
>
> So I think we have no extreme naysayers to Optional. So let me try to
> sum up what we hav
I haven't checked Sebastian's refactored code, but does it use Optionals
as a *field* type? That's misuse (same as using it as an arg), it's
intended solely as method return type.
Radim
On 05/23/2017 05:45 PM, Katia Aresti wrote:
> Dan, I disagree with point 2 where you say "You now have a fiel
Indeed Bela, you're an extreme naysayer! :)
I'm actually trying to get as many comments and arguments out of this
discussion. I hope we will be able to iron out a general recommendation or
approach how we want to treat Optionals.
On Tue, May 23, 2017 at 10:14 PM Bela Ban wrote:
> Actually, I'm
Adding part of your email from REST refactoring thread:
Looking into the code, without considering performance at all, I think
> that you've become too ecstatic about Optionals. These should be used as
> return types for methods, not a) parameters to methods nor b) fields.
> This is a misuse of th
> On 25 May 2017, at 10:00, Sebastian Laskawiec wrote:
> . As it turns out we can use Optionals anywhere, except method returning some
> objects which are not getters.
You can't use it on non getter return types ? Why ?
>
> It is also worth to say that both gentlemen are worried that Optiona
I'm not an Infinispan developer, but I'll chime in anyway. :)
I've never been a fan of Optional. But the theory behind it that made
it acceptable in the first place is that it generally gets optimized away.
Now this theory is only true if you never hold a reference to it in any
persistent mann
On 25 May 2017 at 09:00, Sebastian Laskawiec wrote:
> Adding part of your email from REST refactoring thread:
>
> Looking into the code, without considering performance at all, I think
>> that you've become too ecstatic about Optionals. These should be used as
>> return types for methods, not a)
15 matches
Mail list logo