Re: Records — Dealing with nullable values

[Stephen Colebourne]

On Sun, 15 Dec 2019 at 11:10, Remi Forax <forax at univ-mlv.fr> wrote:
> wrapping my head around what you are saying, if you have a getter that returns an Optional and rarely a constructor or a setter that takes Optional,
> it means that your class is mutable, right ?

No, our classes are all immutable, eg.
https://github.com/OpenGamma/Strata/blob/master/modules/product/src/main/java/com/opengamma/strata/product/TradeInfo.java#L40
Bear in mind that Optional is not serializable, and while we might all
hate Serializable it is a very popular mechanism. Right now, having a
field be an instance of Optional is not really something to recommend
IMO (it certainly divides opinion). Our approach is documented here:
https://blog.joda.org/2015/08/java-se-8-optional-pragmatic-approach.html
(and I suspect has been reasonably widely adopted as an approach).

> we should communicate more on that, records are not beans, i repeat, records are not beans !
> you will be disappointed if you try to replace all your beans by records.

My personal view is that communication won't be enough. The shorter
syntax for records is *so* appealing that it will be used in many,
many places where it really isn't that appropriate. This is why I have
consistently argued that records should only be introduced alongside a
fuller solution for the bean use cases, as outlined in my last mail
[1]. Unlike switch, where I disagree with the adopted solution but any
damage is limited to within a method, over-use of records affects the
API of a project and thus can't be easily rolled back or altered
later. I fully understand the desire to "get records done", but just
like "get brexit done", my view is that an incomplete solution will
result in a worse result during adoption.

Stephen

[1] http://mail.openjdk.java.net/pipermail/amber-dev/2019-December/005383.html