Default value for date/time (original) (raw)
Stephen Colebourne scolebourne at joda.org
Tue May 8 23:54:29 UTC 2018
- Previous message (by thread): Default value for date/time
- Next message (by thread): Default value for date/time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 8 May 2018 at 00:55, John Rose <john.r.rose at oracle.com> wrote:
- make all-zero LD return "LocalDate.default" for toString - make all-zero LD throw DefaultValueException for all other access methods
Isn't this just null under a different name? (Adding a second kind of null is deeply unappealing.)
If so, then saying that LocalDate.default (all zeros) == null doesn't seem terrible. ie. value types could opt in to letting the all zero bits be called null.
BTW, a tangential question. Is the JVM going to guarantee that there never exists an invalid set of bits for a value type? For example, LocalDate would want to prevent the month field being 13, but I've seen no discussion of a validateBits() method for value types.
On 8 May 2018 at 00:47, John Rose <john.r.rose at oracle.com> wrote:
Nope, null is a reference, and is not any kind of value. Our key principle is "codes like a class, works like an int."
From my perspective, the key point here is that LocalDate isn't like int. Its not numeric, it doesn't have a sensible default.
I worry that while the key principle has got the project a long way, it is too hard line when it comes to some potential value types - Currency or Money being other examples where a default is silly, but they are otherwise fully value-like.
throws an exception? (ie. the default can't be observed) "Works like an int" means there is always an observable default. Making defaults unobservable is not "like an int", and is not a project we want to undertake either.
Maybe this could be at the javac level, not the JVM level? (Just exploring ideas) ie. javac could arrange itself such that if code tried to observe a default a DefaultValueObservationException is thrown. This need for this guard should be rare.
Also, the default value of Optional very cleanly boils down to empty, since the reference is null (and/or any extra boolean would be false). In the case of Optional we'd want the default value to play a very definite role in the API.
Is there a list of situations where the default can be observed? This comment suggests an intention that use of Optional could observe the default value (I don't see how myself as the API methods shouldn't allow it).
thanks Stephen
- Previous message (by thread): Default value for date/time
- Next message (by thread): Default value for date/time
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]