Re: Groovy 3 + JDK9 and problems with our Closure

[h2gr]

Why would anyone subclass Closure? Isn't there enough trouble to be 
found elsewhere?


H2


Den 2018-08-08 20:05, skrev Jochen Theodorou:

Hi all,

during JCrete I was playing around with removing some of those
setAccessible calls and found one quite problematic case.

AS many here know we have some implementation details for our
Closures, one of them is the following: You can subclass Closure and
declare a doCall method which will the drive part of the logic
(accepted arguments and such) In fact all of our Closures usages in
Groovy currently end up in one or more doCall methods.

Now the problem is, if you declare an anonymous inner class of a
Closure with a doCall method in Java (yes, we do this in our
codebase), then it is quite difficult to give the runtime (or DGM)
access to this method.

First I thought the super class Closure could have access if the
method is at least public, but AICs are not public, which
automatically restricts access to methods declared in them, not
available otherwise.

I then started to play around with the AIC exhibiting a method handle
to Closure to allow Closure to call the doCall method using the
MethodHandles API. But this will of course add several lines of code
to the subclass, that where not needed before.

And then not to forget about our plan to make our Closures into
something more similar to lambdas in Java.

That did make me think...

(1) maybe Closure should have a factory method that allows a
MethodHandle (or more than one) to be properly registered (ClassValue
I am thinking here), to allow us to call doCall from call

(2) maybe the method should be more convenient and take a Lookup
object and method name instead for the user

(3) even better would be to be able to use a Java lambda for a Closure
but the Java type system does not really allow a nice solution for
that, which means Closure would become:

interface Closure {
  Object call(Object[] args);
  static Closure buildClosure(MethodHandle... h) {...}
  static Closure buildClosure(Lookup lookup, Class baseClass,
String methodName) /*throws ReflectiveOeprationException */{...}
  // plus more here
}

(4) all old code using one of the other call methods or any doCall
would break. Java usage would have to change to either lambdas or one
of the buildClosure methods. Groovy usage could use the MethodHandle
based version and only the MethodHandle based version would include
meta information like the parameter count and types. Accessing this
information lazy could make it a thin wrapper around the handle,
allowing transformations from Closure to SAM cases, while still
holding some kind of reference.

(5) If I think of as lightweight as possible I automatically think of
ValueTypes... Then I wonder... would we rewrite Closure as ValueType
of a MethodHandle at some point (post JDK 11). If yes, should we
investigate more here and maybe go for JKD11+ instead of JDK9 with
Groovy 3? Frankly There is no good reason for me to go with Java 9
anymore, since it is already outdated and not even with LTS.


What do others think about this? Or should I just go an break some
arms and legs... ahm...Groovy code ?

bye Jochen

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

IMHO, there is an ever so subtle difference between navigation - using 
the . operator explictly or implicitly (as with indexing) - and 
arithmetic.


I am personally perfectly happy for my arithmetic expressions to fail 
with any applicable exception if I throw unacceptable values at them.


H2


Den 2018-08-14 13:28, skrev ocs@ocs:

Gentlemen,

some NPE-related problems of today brought me to re-interate one of my
older suggestions.

We have the so-called “safe navigation”[*], which in some cases allows
a null to be propagated out of an expression instead of throwing a
NPE. At the moment, it can be triggered for a particular
sub-expression (like property/method-call and, as of 3, newly also
indexing) using a question mark (e.g., “foo?.bar()” or “foo?[bar]”).

Do please correct me if I am wrong, but far as I know, there still are
expressions which do not allow the “safe mode”, e.g., arithmetic
(“a+b” etc). Furthermore, there are cases when one simply wants a
bigger block of code to contain only null-propagating expressions and
never NPE; in such case, using the question mark syntax is both
inconvenient and error-prone (for it is very easy to forget one of the
lot of question marks needed in such a code, and then get an uncaught
unwanted NPE).

For these reasons, I would suggest adding a new annotation, whose name
might be e.g., “ImplicitSafeNavigation”; it would simply force a
null-propagation to be implicitly and automatically used for *all*
expressions in the annotated scope, i.e., NPE would never be thrown
for them; for example:

===
@ImplicitSafeNavigation class Foo {
 static foo(a,b,c,d,e) {
   a.bar+b*c[d]<(a) a safe-navigation syntax (“foo?.bar”) should be ignored as 
superfluous;

(b) or, whether in this scope it should reverse the behaviour to
trigger an NPE anyway;
(c) or, whether it should be ignored as (a), and aside of that it
would be worth the effort (and technically possible) to add another
syntax to force NPE over a particular sub-expression (e.g.,
“foo!.bar”).

Thanks and all the best,
OC

[*] The name might not be quite apt, for propagating a null is not
inherently safer than NPEing; those are simply two different
approaches, both of which serve best in different circumstances. A
better name would be something like “null-propagating” or “non-NPE”
mode, I guess. Myself, I don't think we should change the name though,
for all are used to it.

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

Den 2018-08-14 14:25, skrev ocs@ocs:

H2,


On 14 Aug 2018, at 1:38 PM, h...@abula.org wrote:
IMHO, there is an ever so subtle difference between navigation - using 
the . operator explictly or implicitly (as with indexing) - and 
arithmetic.


do please correct me if I am wrong, but I understand in Groovy,
arithmetic should be just a convenience thin syntactic sugar over
messages; e.g., “a+b” should be full equivalent to “a.plus(b)”, but
for the syntactic inconvenience:

http://docs.groovy-lang.org/latest/html/documentation/#Operator-Overloading

To me it seems rather unlucky and inconsistent that although I can
write “a?.plus(b)”, I can't do precisely the same with its more
convenient “a+b” equivalent. With other operators it is even more
important, e.g., “a<

As a matter of personal preference, this is fine with me. If you write 
“a?.plus(b)” you are explicitly going out on a limb, and it is 
explicitly visible what you're doing.


However, “a+b” should work as one would expect. What might one expect? I 
guess that something to vote over, but I propose that at the very least, 
one should not expect unexpected errors or errors that are hard to catch 
or test. It's better to catch null-related errors where they occur than 
somewhere else because an entire expression gets evaluated to null 
instead of throwing an exception.


If you want a shorthand notation for “a?.plus(b)” I'd say “a?+b” was 
more consistent (but I am by no means suggesting it).


I am personally perfectly happy for my arithmetic expressions to fail 
with any applicable exception if I throw unacceptable values at them.


As for the (in)convenience of NPE vs null-propagation (or, in other
words, (un)acceptability of nulls inside expressions), I guess it
would rather be in the eye of the beholder.

Do please note though I am not suggesting to remove the possibility to
rely on NPE which you cherish, nor I am suggesting even changing the
default behaviour in the slightest; what I would like to see in Groovy
would be a way to intentionally switch to the non-NPE null-propagating
behaviour where needed by very explicit using of an appropriate
annotation. You, of course, would never be forced to use the thing :)


Of course not, but it would be impossible to know by looking at just the 
code how it is going to behave.


Wouldn't this create potential problems when the code finds its way into 
different project by means of dependencies?





Thanks and all the best,
OC


Ditto! :-)

H2


Den 2018-08-14 13:28, skrev ocs@ocs:

Gentlemen,
some NPE-related problems of today brought me to re-interate one of 
my

older suggestions.
We have the so-called “safe navigation”[*], which in some cases 
allows

a null to be propagated out of an expression instead of throwing a
NPE. At the moment, it can be triggered for a particular
sub-expression (like property/method-call and, as of 3, newly also
indexing) using a question mark (e.g., “foo?.bar()” or “foo?[bar]”).
Do please correct me if I am wrong, but far as I know, there still 
are

expressions which do not allow the “safe mode”, e.g., arithmetic
(“a+b” etc). Furthermore, there are cases when one simply wants a
bigger block of code to contain only null-propagating expressions and
never NPE; in such case, using the question mark syntax is both
inconvenient and error-prone (for it is very easy to forget one of 
the

lot of question marks needed in such a code, and then get an uncaught
unwanted NPE).
For these reasons, I would suggest adding a new annotation, whose 
name

might be e.g., “ImplicitSafeNavigation”; it would simply force a
null-propagation to be implicitly and automatically used for *all*
expressions in the annotated scope, i.e., NPE would never be thrown
for them; for example:
===
@ImplicitSafeNavigation class Foo {
static foo(a,b,c,d,e) {
  a.bar+b*c[d]<(a) a safe-navigation syntax (“foo?.bar”) should be ignored as 
superfluous;

(b) or, whether in this scope it should reverse the behaviour to
trigger an NPE anyway;
(c) or, whether it should be ignored as (a), and aside of that it
would be worth the effort (and technically possible) to add another
syntax to force NPE over a particular sub-expression (e.g.,
“foo!.bar”).
Thanks and all the best,
OC
[*] The name might not be quite apt, for propagating a null is not
inherently safer than NPEing; those are simply two different
approaches, both of which serve best in different circumstances. A
better name would be something like “null-propagating” or “non-NPE”
mode, I guess. Myself, I don't think we should change the name 
though,

for all are used to it.

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

Den 2018-08-14 15:23, skrev ocs@ocs:

H2,


However, “a+b” should work as one would expect


Absolutely. Me, I very definitely expect that if a happens to be null,
the result is null too. (With b null it depends on the details of
a.plus implementation.)


I kind of expected that... :-) I am curious about what others think, 
though.



If you want a shorthand notation for “a?.plus(b)” I'd say
“a?+b” was more consistent


quite, it might be worth adding to the language too; but it is
irrelevant to the current case, where the problem with this approach
is that


there are cases when one simply wants a bigger block of code to
contain only null-propagating expressions and never NPE; in such
case, using the question mark syntax is both inconvenient and
error-prone (for it is very easy to forget one of the lot of
question marks needed in such a code, and then get an uncaught
unwanted NPE).


As for


it would be impossible to know by looking at just the code how it is
going to behave


it would be actually easier than it is now: checking whether an
annotation is used somewhere is _worlds_ easier than checking whether
perhaps the Null.metaclass happens not to be overridden with one
returning null from its invokeMethod — which anyone can do anytime.


Wouldn't this create potential problems when the code finds its way
into different project by means of dependencies?


I think not; quite the contrary. When calling a 3rd party code, you
can't ever know whether the NPE inside of there is caught or not
anyway, can you?


If it's caught, I expect some some default value to be returned or 
exceptional handling to take place which yields the returned value.


If it isn't, I'll get the exception thrown in my face and will be forced 
to deal with it.


I fear that "safe arithmetic evaluation" may generate more null values 
than it should. If there is a difference between the semantics of "no 
value" and "failing to evaluate", I wouldn't want to obscure this by 
representing them the same way.




And again as above, whilst an annotation would not be
self-evident either, it would be at the very least considerably more
intention-revealing and self-documenting than the current
“equivalent” of a 3rd party method

===
def foo() {
  try {
... body which might NPE ...
  } catch (java.lang.NullPointerException npe) {
null
  }
}
===

happens to be now.

Thanks and all the best,
OC


On 14 Aug 2018, at 2:50 PM, h...@abula.org wrote:

Den 2018-08-14 14:25, skrev ocs@ocs:
H2,
On 14 Aug 2018, at 1:38 PM, h...@abula.org wrote:
IMHO, there is an ever so subtle difference between navigation -
using the . operator explictly or implicitly (as with indexing) -
and arithmetic.
do please correct me if I am wrong, but I understand in Groovy,
arithmetic should be just a convenience thin syntactic sugar over
messages; e.g., “a+b” should be full equivalent to
“a.plus(b)”, but
for the syntactic inconvenience:


http://docs.groovy-lang.org/latest/html/documentation/#Operator-Overloading

To me it seems rather unlucky and inconsistent that although I can
write “a?.plus(b)”, I can't do precisely the same with its more
convenient “a+b” equivalent. With other operators it is even
more
important, e.g., “a<

As a matter of personal preference, this is fine with me. If you write
“a?.plus(b)” you are explicitly going out on a limb, and it is
explicitly visible what you're doing.

However, “a+b” should work as one would expect. What might one
expect? I guess that something to vote over, but I propose that at the
very least, one should not expect unexpected errors or errors that are
hard to catch or test. It's better to catch null-related errors where
they occur than somewhere else because an entire expression gets
evaluated to null instead of throwing an exception.

If you want a shorthand notation for “a?.plus(b)” I'd say
“a?+b” was more consistent (but I am by no means suggesting it).


I am personally perfectly happy for my arithmetic expressions to
fail with any applicable exception if I throw unacceptable values
at them.

As for the (in)convenience of NPE vs null-propagation (or, in other
words, (un)acceptability of nulls inside expressions), I guess it
would rather be in the eye of the beholder.
Do please note though I am not suggesting to remove the possibility
to
rely on NPE which you cherish, nor I am suggesting even changing the
default behaviour in the slightest; what I would like to see in
Groovy
would be a way to intentionally switch to the non-NPE
null-propagating
behaviour where needed by very explicit using of an appropriate
annotation. You, of course, would never be forced to use the thing
:)


Of course not, but it would be impossible to know by looking at just
the code how it is going to behave.

Wouldn't this create potential problems when the code finds its way
into different project by means of dependencies?


Thanks and all the best,
OC


Ditto! :-)

H2


Den 2018-08-14 13:28, skrev ocs@ocs:
Gentlemen,
some NPE-related problems

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

Den 2018-08-15 00:28, skrev Jennifer Strater:

Hi OC,

First, I agree with Paul and Andres that it would be nice to see how
well this works outside of groovy core. Hopefully, someone here can
help you make it a reality.

In addition, I would really appreciate it, if, in the future, you did
not use 'gentlemen' to address the entire mailing list.


Good point, and not very gentleman-like! Will 'ladies and gentlemen do'? 
:-)


H2
Gentleman, hopefully...


Best,
Jenn
On Tue, Aug 14, 2018 at 1:28 PM, ocs@ocs  wrote:


Gentlemen,

some NPE-related problems of today brought me to re-interate one of
my older suggestions.

We have the so-called “safe navigation”[*], which in some cases
allows a null to be propagated out of an expression instead of
throwing a NPE. At the moment, it can be triggered for a particular
sub-expression (like property/method-call and, as of 3, newly also
indexing) using a question mark (e.g., “foo?.bar()” or
“foo?[bar]”).

Do please correct me if I am wrong, but far as I know, there still
are expressions which do not allow the “safe mode”, e.g.,
arithmetic (“a+b” etc). Furthermore, there are cases when one
simply wants a bigger block of code to contain only null-propagating
expressions and never NPE; in such case, using the question mark
syntax is both inconvenient and error-prone (for it is very easy to
forget one of the lot of question marks needed in such a code, and
then get an uncaught unwanted NPE).

For these reasons, I would suggest adding a new annotation, whose
name might be e.g., “ImplicitSafeNavigation”; it would simply
force a null-propagation to be implicitly and automatically used for
*all* expressions in the annotated scope, i.e., NPE would never be
thrown for them; for example:

===
@ImplicitSafeNavigation class Foo {
static foo(a,b,c,d,e) {
a.bar+b*c[d]<

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

OCS, your reference to Objective-C is interesting, as is your 
expectation for your code to encounter null values often.


I may be old school, but I think the semantics of null values is 
interesting, as is the semantics of safe navigation.


Safe navigation addresses the matter of nested if statements, perfectly 
in my opinion. What's more, it is explicit in terms of where it applies 
- you can combine safe navigation with "unsafe navigation", allowing 
NPE's to be thrown and nulls to propagate where appropriate.


Unless the same explicit control can be exerted over arithmetic / other 
expressions, I think those two concepts cannot be compared.


I also think any assumption about the semantics of null values are 
problematic. In particular, assuming that any null value in an 
expression should be propagated is not obvious to me.


Cheers,

H2



Den 2018-08-15 04:18, skrev ocs@ocs:

mg,


On 15 Aug 2018, at 3:26 AM, mg  wrote:

Fair enough (I am typing this on my smartphone on vacation, so keep
samples small; also (your) more complex code samples are really hard
to read in my mail reader). It still seems to be a big paradigm
change


I might be missing something of importance here, but I can't see any
paradigm change; not even the slightest shift.

The only change suggested is that one could — in the extent of one
needs that, which would self-evidently differ for different people —
decide whether the “safe” behaviour is explicitly triggered by
using the question-mark syntax, or whether it is implicit.


since regular Java/Groovy programs typically have very little null
values


The very existence of ?. and ?[] suggests it is not quite the case —
otherwise, nobody would ever bother designing and implementing them.


so am not convinced this is worth the effort (and as Jochen pointed
out, there will still be cases where null will just be converted to
"null").


Are there? Given my limited knowledge, I know of none such.
“null?.plus('foo')” yields a null, and so — for a consistency
sake — very definitely should also “null?+'foo'” and
“@ImplicitSafeNavigation ... null+foo”, had they existed.


What I would suggest instead is considering to introduce nil,
sql_null, empty, ... as type agnostic constants in addition to the
existing null in Groovy. That way you could use e.g. nil in your
code, which by definition exhibits your expected behavior, but it
would make the usage more explicit, and one would not need to
switch/bend the existing null semantics...


That's a nice idea; alas, so that it is viable, one would also have to
be able to set up which kind of null is to be returned from
expressions like “aMap['unknownkey']“ or “list.find {
never-matches }” etc.

Thus, instead of my “@ImplicitSafeNavigation(true)” you would have
to use something like “@DefaultNullClass(nil)” — and instead of
“@ImplicitSafeNavigation(false)” you would need something like
“@DefaultNullClass(null)”.

Along with that, you would need a way to return “the current default
null” instead of just null; there would be a real problem with a
legacy code which returns null (but should return “the current
default null” instead), and so forth.

That all said, it definitely is an interesting idea worth checking;
myself, though, I do fear it would quickly lead to a real mess (unlike
my suggestion, which is considerably less flexible, but at the same
moment, very simple and highly intuitive).

Thanks and all the best,
OC


 Ursprüngliche Nachricht 

Von: "ocs@ocs" 
Datum: 15.08.18 00:53 (GMT+00:00)
An: dev@groovy.apache.org
Betreff: Re: suggestion: ImplicitSafeNavigation annotation

mg,


On 15 Aug 2018, at 1:33 AM, mg  wrote:

That's not how I meant my sample eval helper method to be used :-)

(for brevity I will write neval for eval(true) here)

What I meant was: How easy would it be to get a similar result to
what you want, by wrapping a few key places (e.g. a whole method
body) in your code in neval { ... } ? Evidently that would just
mean that any NPE inside the e.g. method would lead to the whole
method result being null.


Which is a serious problem. Rarely you want „a whole method be
skipped  (and return null) if anything inside of it happens to be
null“. What you normally want is the null-propagation, e.g.,

def foo=bar.baz[bax]?:default_value;
... other code ...

The other code is _always_ performed and _never_ skipped (unless
another exception occurs of course); but the null-propagation makes
sure that if bar or bar.baz happens to be a null, then default_value
is used. And so forth.


To give a simple example:

final x = a?.b?.c?.d

could be written as

final x = neval { a.b.c.d }


Precisely. Do please note that even your simple example did not put
a whole method body into neval, but just one sole expression
instead. Essentially all expressions — often sub-expressions,
wherever things like Elvis are used — would have to be embedded in
nevals separately. Which is, alas, far from feasible.


Of course the two expressions a

Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

See comment below.

Den 2018-08-15 14:55, skrev ocs@ocs:

H2,


On 15 Aug 2018, at 9:47 AM, h...@abula.org wrote:

OCS, your reference to Objective-C is interesting, as is your
expectation for your code to encounter null values often.


In my experience, a null is (should be, at the very least) a
first-class citizen, value which simply means “there is no object
there”. In normal code it happens all the time, e.g., if you check a
map with a key which happens not to be there, or if you use _find_
with a condition which happens not to match any of the items in the
list, etc.


I may be old school, but I think the semantics of null values is
interesting, as is the semantics of safe navigation.


Actually, all this NPE stuff (and its consequences) is pretty
new-school :)

The aforementioned Objective C (of eighties!) has a couple of very
simple rules:
- wherever an expression returns an object, it may return a _nil_;
- whenever a message[*] is sent to a _nil_, it is a very quick and
efficient empty operation, whose return value is again _nil_.

[*] in ObjC, you use an object exclusively[**] through sending
messages: you send a message without any argument for a property
getter, you send a message with one argument for a property setter,
you send a message with an arbitrary number of arguments for a method
call, etc.
[**] but for the access to instance variables (more or less
“fields”), which is sort-of similar to plain-C structs, and
happens from the declaring class code only, usually is limited to the
property accessor methods and never used outside of them.

Whilst I do completely appreciate that tastes and experiences do
differ, well, myself, in thirty-odd years of using this paradigm daily
and after an uncounted zillions source lines in projects some of which
have 25-odd-year lifespan, were made for NeXTSTEP ages ago and are
maintained for macOS of today, I am yet to find any drawback of this
approach. Cases when a bug has been caused by unintended and uncaught
sending a message to a _nil_ are extremely rare (myself I can recall
about three of such cases in all those years), whilst the advantages
for code readability, conciseness, and robustness are tremendous.


Safe navigation addresses the matter of nested if statements,
perfectly in my opinion.


Absolutely. Nevertheless, there's absolutely no point why it should be
limited to methods — compare e.g., the following case (very simple
and thus a bit artificial to keep concise):

===
interface TreeNode {
  TreeNode createChildIfPossible(String name); // if possible, creates
and returns a new named child; null if not possible
}
void makeSubtreeIfPossible(TreeNode tn) { // here, we do not care
whether successful; just want to make as big a subtree as possible
  def foo=tn?.createChildIfPossible('foo')
  foo?.createChildIfPossible('bar')?.createChildIfPossible('baz')

foo?.createChildIfPossible('bax')?.createChildIfPossible('baz')?.createChildIfPossible('last')
}
===

Thanks to ?. we have dodged the necessity of super-ugly ifs, but
still, the result is sort of at the ugly javaish side. Can we get
groovier? Well of course we can:

===
class TreeNode {
  def leftShift(object) { this.createChildIfPossible(object) }
}
void makeSubtreeIfPossible(TreeNode tn) {
  def foo=tn?<<'foo'
  foo?<<'bar'?<<'baz'
  foo?<<'bax'?<<'baz'?<<'last'
}
===


This looks like a mix of effects and side effects.

The effect: The leftShift(object) method is supposed to return the 
TreeNode instance created by the createChildIfPossible(String name) 
method allowing subsequent calls as long as the return value is not 
null.


The side effect: At the same time, createChildIfPossible(String name) 
and therefore also leftShift(object) is supposed to build a tree 
structure, mutating the internals of the TreeNode tn argument to the 
makeSubtreeIfPossible(TreeNode tn) method.


I like null propagation in evaluation chains which generate a some value 
to be assigned to a variable, but the same ting as a mechanism to stop 
creating side effects is not right at all in my book.



Oh, oops! We can't do that, for we do not have “safe navigation”
for operators, and thus, if we want to use the << for adding a child,
we would have to get back to ugly Javaish ifs, which I would not dare
to show lest some reader might get sick :)


What's more, it is explicit in terms of where it applies - you can
combine safe navigation with "unsafe navigation", allowing NPE's to
be thrown and nulls to propagate where appropriate.


Agreed, and where one needs just an _occasional_ null-propagation,
it's perfect (or, as the example above shows, _would be_, if it could
be used with all the operators instead of just with the method call,
property access and indexing ones).

Nevertheless, there are cases where one needs the null-propagation not
just occasionally, but very often (if not exclusively) in a piece of
code — do not all the ?'s in the examples above look ugly? And even
if you like them, they very definitely make 

Re: logo permission

[h2gr]

No. Never.

Are you sure you're not biased in any say? Not even a little? Come on...

Cheers,

Haakon Hansen
The "communist" kingdom of Norway

---

Den 2020-05-21 03:48, skrev MG:

NEVER ? Not even a little ? Come on...

Socialist/communist red star:






Scale horizontally:



Change fill color, add black outline:




Add font-of-choice groovy text:















That's why I jokingly call it the communist logo.
I personally agree with the recent critique towards the logo looking
old and not entirely professional, but apart from that the fact that
it is quite wide makes it not a good fit with regards to being used as
an icon:




It also does not scale well down to small size:



But it was just a suggestion,
Cheers,
mg



On 20/05/2020 22:22, Søren Berg Glasius wrote:
I have NEVER considered the Groovy logo to look like the communist 
star. As a matter of fact, I find the Groovy Star logo easily 
recognizable, and in the given case, I like it over the circled G.


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 ons. 20. maj 2020 kl. 21.47 skrev MG >:


I have added a comment suggesting considering using the Groovy
"icon"/Jira logo instead of the communist star one
(https://en.wikipedia.org/wiki/Red_star) G-)
Cheers,
mg

On 20/05/2020 20:00, Carl Marcum wrote:

I have attached the screenshots to this issue [1].
Please let me know if you have any questions.

[1] https://issues.apache.org/jira/browse/GROOVY-9564

On Wed, May 20, 2020 at 6:32 AM Carl Marcum mailto:cmar...@apache.org>> wrote:

Hi Paul,

Having trouble attaching the image to Jira for some reason so
I'm
getting with infra about it.

I'll post back the issue when created.

Thanks,
Carl

On 5/19/20 10:31 PM, Paul King wrote:
> Hi Carl,
>
> This sounds like the kind of use of the Groovy logo that
we'd like to
> support. Can I ask you to create a Groovy Jira issue and
attach a
> screenshot.
>
> Thanks, Paul.
>
>
> On Wed, May 20, 2020 at 11:40 AM Carl Marcum
mailto:cmar...@apache.org>
> >> 
wrote:

>
>     Hello,
>
>     I'm wrapping up work on an Apache OpenOffice extension
to add Apache
>     Groovy as a scripting language to OpenOffice.
>
>     The extensions require a small thumbnail image that
displays in the
>     Extension Manager for each installed extension beside
the extension
>     title and description.
>
>     I request to use the Groovy star logo for this 
thumbnail if

>     possible as
>     Groovy is the whole point of the extension.
>
>     Although I'm on the AOO PMC this extension is a
personal project
>     for the
>     time being and I plan on releasing it through our
> extensions.openoffice.org

 site
>     under the Apache license.
>
>     I can send a screenshot if you would like to see the
intended usage.
>     I'm subscribed to dev@ or feel free to contact me 
directly.

>
>     Best regards,
>     Carl Marcum
>

Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

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 :



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?

Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

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 :

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?

Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

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 :

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?

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

Re. 5:

But there is nothing to fill up with zeroes...

BR;H2

Den 2021-11-18 15:11, skrev MG:

I don't think that is correct: Time intervals for days, etc always
need to be chosen so they are overlap free*, i.e. mathematically
speaking the interval is closed on one end and open on the other, with
the start of the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...

For finite resolution (i.e. computers; assuming 3 didgits of
millisecond precision) and the example of 1 day as interval length,
this would mean that the interval of a day looks like:
[date 00:00:00.000, date 23:59:59.999]
or
[date 00:00:00.000, date+1 00:00:00.000[

To sum up:

1. I have used the convention to chose the start of the interval to be
   closed, and the end to be open (i.e. t0 is in the interval, whereas
   t1 is not), which I have encountered time and time again, and
   therefore assume to be widely used.
2. Using midnight of the following day only makes sense if you invert
   the open-closed end of the interval, which as I said to me is quite
   unusal.
3. Using an application dependent time such as 21:00, 23:00, 01:00,
   02:00 or 08:00 (because that is "when the backup runs or has
   finished") is certainly something which no one can expect to be the
   convention in a generally used language, and would imho be a
   terrible idea (apart from the fact that there is no concept on how
   to choose one over the other). It would also violate the sort order
   of Date with DateTime, in the most unexpected way. Applications that
   want/need that will have to use DateTime throughout.
4. As I have said, the only other implicit time I would consider
   slightly viable is noon, but as far as least surprise, sort order
   behavior, etc goes, using the start of the day is imho the singular
   choice.
5. (Using 00:00:00.000 also follows the time honored IT convention of
   "filling things up with zeroes", if not explicitly told differently
   ;-) )

Cheers,
mg

*Otherwise a point in time could be in more than one interval (e.g.
belong to more than one day).


On 18/11/2021 14:22, Jochen Theodorou wrote:

On 17.11.21 20:28, MG wrote:
[...]

 3. I have never encountered any other assumption than the one that a
    Date carries the implicit time of midnight (00:00:00.000...). 
What
    other time would one logically pick, given that time intervals 
are
    by convention typically closed on the left and open on the right 
?


But you have here already trouble. you can take the start of the day, 
or

the end of the day. both is midnight, both based on the same date, but
they are basically 24h apart. In my last project we mostly used end of
the day for example. And in some parts actually 2:00 in the morning,
because it is the time to run after some processes... which did not
proof to be a good idea btw.

bye Jochen

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

Hi!

Yes, I got that, but step 1 breaks it IMHO.

It' just as wrong as assuming that a year is equivalent to New Year's 
Day that year (at midnight, even).


Filling up with zeroes works when comparing integer numbers with real 
numbers, but that's about it.


For one thing, the integer / real number comparison works both ways. The 
same cannot be said about LocalDateTime and LocalDate.


Sorry...

BR;H2

Den 2021-11-18 16:01, skrev MG:

1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go


On 18/11/2021 15:45, h...@abula.org wrote:

Re. 5:

But there is nothing to fill up with zeroes...

BR;H2

Den 2021-11-18 15:11, skrev MG:

I don't think that is correct: Time intervals for days, etc always
need to be chosen so they are overlap free*, i.e. mathematically
speaking the interval is closed on one end and open on the other, 
with

the start of the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...

For finite resolution (i.e. computers; assuming 3 didgits of
millisecond precision) and the example of 1 day as interval length,
this would mean that the interval of a day looks like:
[date 00:00:00.000, date 23:59:59.999]
or
[date 00:00:00.000, date+1 00:00:00.000[

To sum up:

1. I have used the convention to chose the start of the interval to 
be
   closed, and the end to be open (i.e. t0 is in the interval, 
whereas

   t1 is not), which I have encountered time and time again, and
   therefore assume to be widely used.
2. Using midnight of the following day only makes sense if you invert
   the open-closed end of the interval, which as I said to me is 
quite

   unusal.
3. Using an application dependent time such as 21:00, 23:00, 01:00,
   02:00 or 08:00 (because that is "when the backup runs or has
   finished") is certainly something which no one can expect to be 
the

   convention in a generally used language, and would imho be a
   terrible idea (apart from the fact that there is no concept on how
   to choose one over the other). It would also violate the sort 
order
   of Date with DateTime, in the most unexpected way. Applications 
that

   want/need that will have to use DateTime throughout.
4. As I have said, the only other implicit time I would consider
   slightly viable is noon, but as far as least surprise, sort order
   behavior, etc goes, using the start of the day is imho the 
singular

   choice.
5. (Using 00:00:00.000 also follows the time honored IT convention of
   "filling things up with zeroes", if not explicitly told 
differently

   ;-) )

Cheers,
mg

*Otherwise a point in time could be in more than one interval (e.g.
belong to more than one day).


On 18/11/2021 14:22, Jochen Theodorou wrote:

On 17.11.21 20:28, MG wrote:
[...]
 3. I have never encountered any other assumption than the one that 
a
    Date carries the implicit time of midnight (00:00:00.000...). 
What
    other time would one logically pick, given that time intervals 
are
    by convention typically closed on the left and open on the 
right ?


But you have here already trouble. you can take the start of the 
day, or
the end of the day. both is midnight, both based on the same date, 
but
they are basically 24h apart. In my last project we mostly used end 
of

the day for example. And in some parts actually 2:00 in the morning,
because it is the time to run after some processes... which did not
proof to be a good idea btw.

bye Jochen

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

Well, one example:

A campaign price is valid for the duration of January 2022.

In terms of LocalDate, this could be expressed as from 2022-01-01 
(inclusive) to 2022-01-31 (inclusive).


In terms of LocalDateTime, this could be expressed as from 2022-01-01 at 
midnight (inclusive) to 2022-02-01 at midnight (exclusive).


Note the difference with the to-date being inclusive while the 
to-datetime being exclusive.


This makes sense because a date has a resolution of one day and thus 
contains all times within that day.


Yes, one could argue, but then again - ask a user who might define such 
a campaign price's valid period what is "right" for them, and try to 
explain why it has to be different (i.e. inclusive/exclusive because of 
code concerns.


BR;H2

Den 2021-11-18 17:42, skrev MG:

A day, year, etc is evidently never equal to an actual point in time,
since it is an interval. The question for me is: Can we convert the
Date to a DateTime so that it has an ordering which is
helpful/meaningful in practice, without inviting unexpected bugs etc ?

So what concrete scenario do you see where the implicit attaching of
00:00:00 to a Date for the sake of comparison:

1.   Leads to a program error in a practical scenario (i.e. not
   constructed and not for applications which control their data types
   and should evidently go DateTime all the way) ?
2. Leads to an unexpected result, i.e. "does not work for the developer
   or user" ?

You might assume I am dead set on getting this into Groovy, but that
is not the case. It is just that the counter arguments I have seen to
this point seemed quite weak to me, so I have taken the position to
argue for it (wich is the direction I am leaning to) - but convince me
otherwise (saying "it is just wrong on principal" won't do that,
though, unless I buy into your principle, which I oftend do not, since
for me what is relevant is mostly whether it works in practice).

Cheers,
mg

PS:  The "filling with zeroes" was a fluff comment - that's why it is
in brackets and has an according smiley at the end ;-)



On 18/11/2021 16:25, h...@abula.org wrote:

Hi!

Yes, I got that, but step 1 breaks it IMHO.

It' just as wrong as assuming that a year is equivalent to New Year's 
Day that year (at midnight, even).


Filling up with zeroes works when comparing integer numbers with real 
numbers, but that's about it.


For one thing, the integer / real number comparison works both ways. 
The same cannot be said about LocalDateTime and LocalDate.


Sorry...

BR;H2

Den 2021-11-18 16:01, skrev MG:

1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go


On 18/11/2021 15:45, h...@abula.org wrote:

Re. 5:

But there is nothing to fill up with zeroes...

BR;H2

Den 2021-11-18 15:11, skrev MG:

I don't think that is correct: Time intervals for days, etc always
need to be chosen so they are overlap free*, i.e. mathematically
speaking the interval is closed on one end and open on the other, 
with

the start of the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...

For finite resolution (i.e. computers; assuming 3 didgits of
millisecond precision) and the example of 1 day as interval length,
this would mean that the interval of a day looks like:
[date 00:00:00.000, date 23:59:59.999]
or
[date 00:00:00.000, date+1 00:00:00.000[

To sum up:

1. I have used the convention to chose the start of the interval to 
be
   closed, and the end to be open (i.e. t0 is in the interval, 
whereas

   t1 is not), which I have encountered time and time again, and
   therefore assume to be widely used.
2. Using midnight of the following day only makes sense if you 
invert
   the open-closed end of the interval, which as I said to me is 
quite

   unusal.
3. Using an application dependent time such as 21:00, 23:00, 01:00,
   02:00 or 08:00 (because that is "when the backup runs or has
   finished") is certainly something which no one can expect to be 
the

   convention in a generally used language, and would imho be a
   terrible idea (apart from the fact that there is no concept on 
how
   to choose one over the other). It would also violate the sort 
order
   of Date with DateTime, in the most unexpected way. Applications 
that

   want/need that will have to use DateTime throughout.
4. As I have said, the only other implicit time I would consider
   slightly viable is noon, but as far as least surprise, sort 
order
   behavior, etc goes, using the start of the day is imho the 
singular

   choice.
5. (Using 00:00:00.000 also follows the time honored IT convention 
of
   "filling things up with zeroes", if not explicitly told 
differently

   ;-) )

Cheers,
mg

*Otherwise a point in time could be in more than one interval (e.g.
belong to more than one day).


On 18/11/2021 14:22, Jochen Theodorou wrote:

On 17.11.21 20:28, MG wrote:
[...]
 3. I have never encountered any other assumption than the one 
that a
    Date carries the implicit time of midnight (00:00:00.000...). 
W

Re: [EXT] Re: A feature request: comparing LocalDate and LocalDateTime using built-in operators.

[h2gr]

Den 2021-11-18 22:47, skrev MG:

If you want to voluntarily mix Date and DateTime in your application...


I certainly don't!

But that's what sparked this discussion, isn't? Otherwise there would be 
no pears and apples to compare in the first place, would there?



I think we made our points, I suggest we wait what Mr. Groovy (aka
Paul) has to say, who might easily shoot this down with an argument no
one has yet considered... G-)


Certainly! Let's! ;-)

BR;H2


On 18/11/2021 20:40, h...@abula.org wrote:

Well, one example:

A campaign price is valid for the duration of January 2022.

In terms of LocalDate, this could be expressed as from 2022-01-01 
(inclusive) to 2022-01-31 (inclusive).


In terms of LocalDateTime, this could be expressed as from 2022-01-01 
at midnight (inclusive) to 2022-02-01 at midnight (exclusive).


Note the difference with the to-date being inclusive while the 
to-datetime being exclusive.


This makes sense because a date has a resolution of one day and thus 
contains all times within that day.


Yes, one could argue, but then again - ask a user who might define 
such a campaign price's valid period what is "right" for them, and try 
to explain why it has to be different (i.e. inclusive/exclusive 
because of code concerns.


BR;H2

Den 2021-11-18 17:42, skrev MG:

A day, year, etc is evidently never equal to an actual point in time,
since it is an interval. The question for me is: Can we convert the
Date to a DateTime so that it has an ordering which is
helpful/meaningful in practice, without inviting unexpected bugs etc 
?


So what concrete scenario do you see where the implicit attaching of
00:00:00 to a Date for the sake of comparison:

1.   Leads to a program error in a practical scenario (i.e. not
   constructed and not for applications which control their data 
types

   and should evidently go DateTime all the way) ?
2. Leads to an unexpected result, i.e. "does not work for the 
developer

   or user" ?

You might assume I am dead set on getting this into Groovy, but that
is not the case. It is just that the counter arguments I have seen to
this point seemed quite weak to me, so I have taken the position to
argue for it (wich is the direction I am leaning to) - but convince 
me

otherwise (saying "it is just wrong on principal" won't do that,
though, unless I buy into your principle, which I oftend do not, 
since

for me what is relevant is mostly whether it works in practice).

Cheers,
mg

PS:  The "filling with zeroes" was a fluff comment - that's why it is
in brackets and has an according smiley at the end ;-)



On 18/11/2021 16:25, h...@abula.org wrote:

Hi!

Yes, I got that, but step 1 breaks it IMHO.

It' just as wrong as assuming that a year is equivalent to New 
Year's Day that year (at midnight, even).


Filling up with zeroes works when comparing integer numbers with 
real numbers, but that's about it.


For one thing, the integer / real number comparison works both ways. 
The same cannot be said about LocalDateTime and LocalDate.


Sorry...

BR;H2

Den 2021-11-18 16:01, skrev MG:

1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go


On 18/11/2021 15:45, h...@abula.org wrote:

Re. 5:

But there is nothing to fill up with zeroes...

BR;H2

Den 2021-11-18 15:11, skrev MG:
I don't think that is correct: Time intervals for days, etc 
always

need to be chosen so they are overlap free*, i.e. mathematically
speaking the interval is closed on one end and open on the other, 
with

the start of the next interval being the end of the last:
[t0,t1[ , [t1,t2[ , ...

For finite resolution (i.e. computers; assuming 3 didgits of
millisecond precision) and the example of 1 day as interval 
length,

this would mean that the interval of a day looks like:
[date 00:00:00.000, date 23:59:59.999]
or
[date 00:00:00.000, date+1 00:00:00.000[

To sum up:

1. I have used the convention to chose the start of the interval 
to be
   closed, and the end to be open (i.e. t0 is in the interval, 
whereas

   t1 is not), which I have encountered time and time again, and
   therefore assume to be widely used.
2. Using midnight of the following day only makes sense if you 
invert
   the open-closed end of the interval, which as I said to me is 
quite

   unusal.
3. Using an application dependent time such as 21:00, 23:00, 
01:00,

   02:00 or 08:00 (because that is "when the backup runs or has
   finished") is certainly something which no one can expect to 
be the

   convention in a generally used language, and would imho be a
   terrible idea (apart from the fact that there is no concept on 
how
   to choose one over the other). It would also violate the sort 
order
   of Date with DateTime, in the most unexpected way. 
Applications that

   want/need that will have to use DateTime throughout.
4. As I have said, the only other implicit time I would consider
   slightly viable is noon, but as far as least surprise, sort 
order
   behavior, etc goes, using the start