Re: Instant.now(Clock) and InstantSource

[Naoto Sato]

+1 for not deprecating the method that takes Clock. It would give 
existing users unnecessary warnings.


Naoto

On 6/4/24 12:17 AM, Stephen Colebourne wrote:

On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever  wrote:

It feels a bit strange that you can't pass an `InstantSource` to `Instant.now(...)`, but 
you _can_ pass a `Clock` (which of course has a "useless" `ZoneId` when 
creating an `Instant`). Therefore, I'd like to propose one of the following API changes:

1) adding `Instant.now(InstantSource)`
2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`


I have no problem with adding `Instant.now(InstantSource)`, but I
think deprecating the `Clock` method is unnecessary (given it will
never be removed AFAICT, and it is no doubt in widespread use).
Stephen

Re: Instant.now(Clock) and InstantSource

[Stephen Colebourne]

On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever  wrote:
> It feels a bit strange that you can't pass an `InstantSource` to 
> `Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a 
> "useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to 
> propose one of the following API changes:
>
> 1) adding `Instant.now(InstantSource)`
> 2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`

I have no problem with adding `Instant.now(InstantSource)`, but I
think deprecating the `Clock` method is unnecessary (given it will
never be removed AFAICT, and it is no doubt in widespread use).
Stephen

Instant.now(Clock) and InstantSource

[Kurt Alfred Kluever]

Hi folks,

It feels a bit strange that you can't pass an `InstantSource` to
`Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
"useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
propose one of the following API changes:

1) adding `Instant.now(InstantSource)`
2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`

(I believe removing `Instant.now(Clock)` would be binary compatible, so
that's not an option, right?)

There's also a related discussion about adding an InstantSource-based
static factory method to the "local" types (e.g.,
`LocalDate.now(InstantSource, ZoneId)`). However, I always avoid using the
static factories on those types and have been quite happy with the fluent
pattern instead (e.g., `instantSource.instant().atZone(...).toLocalDate()`).

Thoughts?

-- 
kak