Value types design decisions

[Quân Anh Mai]

Hi,

I think the key idea is that the zero instance of an implicitly
constructible class is an initialized object. In the future, when ! is
extended to other classes then the object must be explicitly instantiated
to be able to be assigned to a ! type, hence the name implicit constructor.

Regards,
Quan Anh

On Sun, 21 Jan 2024 at 04:34, David Alayachew <davidalayachew at gmail.com>
wrote:

> 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/20240121/58e183d4/attachment.htm>