Well, yea, sure, that is the Java way of doing things: Making every
little bit explicit, leading to non-concise, boiler-plate heavy code
(which is not always good to read either, since all that explicitness
often obsfuscates what is really going on, running counter to the
original intention of being so explicit).
On the other side are languages that allow one to achieve the same
result in a much more compact manner. This power sometimes comes with
the drawback, that some allowed operations might be considered an error
in some situations, or at least results might be surprising, the default
automatism is not what many people want/need, etc.
So one has to weigh what automatisms to allow and which to avoid since
their risk-reward is not worth it.
Examples in Groovy for things which I wish it would not suppport/allow:
1. Assuming a retun value of null for void methods
2. Treating empty collections as boolean false, especially in ?: constructs
On the other hand there are of course a great number of things Groovy
allows, conversions it does, etc, that Java does not, which make it a
joy to use.
So arguments like these cannot be settled in a general manner (or they
can, but then your language of choice is Java, not Groovy), but need to
be evaluated case by case.
Maybe extension methods are enough for the concrete case, but I think we
should still consider if this should not be a general extension to Groovy.
Cheers,
mg
On 18/11/2021 12:35, h...@abula.org wrote:
Correction:
Argh.
As you probably already have spotted, I should have written this:
localDateTime.toLocalDate().equals(localDate)
or
localDateTime.toLocalDate() == localDate
Now apples are compared with apples, the non-apple part is ignored,
and nothing is assumed beyond the lowest resolution.
BR;H2
Den 2021-11-17 21:56, skrev h...@abula.org:
I think resolution is a key word here, and I agree that it is proper
to be explicit about what one assumes.
That said, if one assumption were to be made, why not compare what is
comparable and not what isn't, e.g.
localDateTime.getDateTime().equals(localDate)
or
localDateTime.dateTime == localDate
Doesn't code like this look agreeable enough?
BR; Haakon Hansen, Norway
--
Den 2021-11-17 13:00, skrev Rachel Greenham:
I think this is part of the argument to be had with the *java*.time
api (it’s not really a groovy matter tbh). A LocalDate is a time with
a resolution of one day, it is not implicitly midnight, just as a
LocalTime does not imply *any* day, including today, just a time of
day, and a LocalDateTime does not compare to a ZonedDateTime because
you really need that zone info, and it could be dangerous to assume a
timezone. so the API stops you acting as if that’s ok.
It’s therefore proper to expect to do the conversion.
theLocalDate.atStartOfDay() < theLocalDateTime (or
theLocalDate.atStartOfDay().isBefore(theLocalDateTime()) )
That’s the conceptual problem with wanting a convenience of being able
to compare different time types *without knowing what they are*. It
means you may be embedding assumptions in a library that aren’t as
global as you might think they are.
--
Rachel Greenham
rac...@merus.eu
On 17 Nov 2021, at 11:53, h...@abula.org wrote:
Here, we represent `java.time.LocalDate` as a
`java.time.LocalDateTime` at
midnight.
Just off the top of my head, should the LocalDate match
LocalDateTime only at midnight? Or should it match any point in
time during that date? Surely it's April fool's day for the entire
duration of April 1st?
BR; Haakon Hansen, Norway
Den 2021-11-17 12:28, skrev Søren Berg Glasius:
I think this is a very good idea, and give a +1 for the idea and
implementation.
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.
Den tir. 16. nov. 2021 kl. 15.24 skrev ssz <sss.z...@gmail.com>:
Hello everyone,
Before creating a PR (or\and an issue in Jira) I would like to
discuss a
possible feature.
In our product we need the ability to compare
`java.time.LocalDate` and
`java.time.LocalDateTime` objects easily without knowing the
exact type.
For this we have historical reasons: we have a groovy-based
engine and a
lot of client scripts with date comparison.
Until recently, we used a customized version of joda-time, that
allows
such operations.
As practice has shown, it was very convenient.
But now for some reasons we have decided to abandon joda-time in
favor of
pure java-time.
So, in order not to break anyone's scripts it would be nice for
us if
groovy could support comparisons of those date-objects out of the
box.
To demonstrate what I mean here is a draft:
https://github.com/greendatasoft/groovy/commit/c55d722e6b6ead9d6e0123835c62a5fa4f525ffe
Here, we represent `java.time.LocalDate` as a
`java.time.LocalDateTime` at
midnight.
It seems this way can't break any code, and at the same time it
would be
user-friendly.
But for those who have weird logic with exception handling, there
is a
"groovy.compare.local-date-and-datetime" option, which allows to
return
back the original behaviour.
Please tell me what you think.
Can I proceed with PR?
Or maybe there is a better way to customize groovy to achieve the
same
behaviour?
