Value types design decisions

[David Alayachew]

Hello Brian,

Just wanted to ask about this point below.

> These two examples (conveniently, from the same package)
> tell us a truth about modeling data with value objects:
> some classes have reasonable defaults (and we can exploit
> this to optimize their treatment, and can freely let
> people use uninitialized variables, as we do for
> primitives today), and some do not (and hence we need
> either to engage nullability, or work very hard to ensure
> that an object cannot possibly be used uninitialized.

Oh woah, what does it look like to prevent an object to be used
uninitialized? We don't have any compiler-enforced ways of doing this,
right? You are talking about just manually code reviewing each use of the
class to try and hope to catch any misuse?

And if you mean manual review, is that really something that would be worth
the effort? Aside from the most trivial situations, I can't think of an
example.

Thank you for your time and help!
David Alayachew

On Sat, Jan 20, 2024 at 2:23 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Forgot to address this part.
>
> On 1/20/2024 2:00 AM, Smith Wilson wrote:
> > It could solve problems with such classes like LocalDate which require
> > more special zeroInstance (1970-1-1) than value with pure defaults.
>
> The key thing to realize about LocalDate is that while it is a good
> candidate for being a value type, there is *literally no* good default
> value.  Jan 1 1970 is not a good default value, as we've all seen by
> getting emails that tell us our subscriptions are going to expire 54
> years ago.  No other specific date is a good default either.  This is a
> statement about the _domain_; there is no good default.  (And when an
> abstraction does not have a good default, null is your friend.)
>
> Other classes have good defaults; Duration is such an example.
>
> These two examples (conveniently, from the same package) tell us a truth
> about modeling data with value objects: some classes have reasonable
> defaults (and we can exploit this to optimize their treatment, and can
> freely let people use uninitialized variables, as we do for primitives
> today), and some do not (and hence we need either to engage nullability,
> or work very hard to ensure that an object cannot possibly be used
> uninitialized.
>
> The reason that "implicit constructor" is a thing is that, even after
> we've identified that a class is a value class, we still have to
> identify something else: whether it is implicitly constructible or
> requires explicit construction.  (There's other ways to frame it, of
> course, but the key is that this has to be in the programming model.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240120/aea7a0bd/attachment.htm>