<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But do those two use cases really need an abstraction? Is there really value in a Range interface?<br>Given the two classes above, which are IMO candidates for the JDK, they work fine as isolated value types without a generalized abstraction.</blockquote><div><br></div><div>I see this a bit differently. In the examples you provided, there are basically no methods that would somehow indicate that Interval is something more than generic Range<Instant> besides toDuration(), and same goes for LocalDateRange. Therefore, I see generic ranges not as "abstracting" ranges, but rather adapting them for the general case. Range<Instant> and Interval are roughly identical, with differences easily coverable by few static methods.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Similarly, I'm not sure what a Range value type would accomplish. Don't get me wrong - if fully integrated into the language, with literals and looping syntax there might be a case, but we are a long way from that.</blockquote><div><br></div><div>Well, every feature started somewhere. There is clearly a demand for range support, both numeric, chronological, and potentially many others. Amber is considering integrating ranges as patterns, so anyway internal representation will be needed.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry to be a bit down given the massive effort made here, but the harsh truth is that I've yet to see a "Range" API that I like, and I especially find mixing bounded/unbounded and inclusive/exclusive gets complicated and unpleasant very fast. </blockquote><div><br></div><div>Your opinion is valuable too. I am not pushing on integrating this changes, PR mostly serves research purpose, and final form could (and most likely will) differ a lot from the current state of API.</div><div><br></div><div>Ranges are indeed not easy to model, they always could use some syntax-level dsl. If the demand shows to be high enough, this may also be the subject of discussion. Nevertheless, ranges in general are really popular. Chronological ranges are one of the most common business object attributes, numeric ranges could be useful for research and visualization etc. For now, I will continue on evolving the API, to see if it is possible to arrive at the point where the API is smooth enough to become a candidate.<br><br>PS: Regarding chronological ranges specifically, this was my motivation in the first place (<a href="https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I">https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I</a> was initially a fan of nominal date and time ranges, but when I started modeling the API, I discovered that, surprisingly, there is little to none tdatetime-specific operations that could be made on ranges. Therefore, I came to the conclusion that ranges generalize too well to miss on this. Some people here argue it is too strict to oblige range elements to be comparable, let alone chronological types.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 23, 2024 at 11:24 PM Stephen Colebourne <<a href="mailto:scolebourne@joda.org">scolebourne@joda.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've always found the generic concept of a "range" tricky to express<br>
in a sensible API. When authoring Joda-Time and java.time I avoided it<br>
as much as possible.<br>
<br>
ThreeTen-Extra has two classes - Interval and LocalDateRange - which<br>
cover the two main use cases.<br>
<a href="https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html" rel="noreferrer" target="_blank">https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html</a><br>
<br>
But do those two use cases really need an abstraction? Is there really<br>
value in a Range interface?<br>
Given the two classes above, which are IMO candidates for the JDK,<br>
they work fine as isolated value types without a generalized<br>
abstraction.<br>
<br>
Similarly, I'm not sure what a Range value type would accomplish.<br>
Don't get me wrong - if fully integrated into the language, with<br>
literals and looping syntax there might be a case, but we are a long<br>
way from that. (ie. some language designs are built around ranges as a<br>
first class concept, but Java isn't, and I have doubts that it would<br>
be a good fit to try and pivot that way now.) In particular, I<br>
struggle with a generified Range type - it just "feels wrong" to me.<br>
<br>
Sorry to be a bit down given the massive effort made here, but the<br>
harsh truth is that I've yet to see a "Range" API that I like, and I<br>
especially find mixing bounded/unbounded and inclusive/exclusive gets<br>
complicated and unpleasant very fast. And that is before you consider<br>
discrete versus continuous.<br>
Stephen<br>
<br>
<br>
On Sun, 22 Sept 2024 at 20:02, Olexandr Rotan<br>
<<a href="mailto:rotanolexandr842@gmail.com" target="_blank">rotanolexandr842@gmail.com</a>> wrote:<br>
><br>
> Hello everyone! I am writing here today to invite everyone to participate in the discussion regarding the Range APi proposal I have made into JDK. Here is the pull request link: <a href="https://github.com/openjdk/jdk/pull/21122" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/21122</a>, and PR text:<br>
><br>
> This pull request describes the methods of the Range<T> interface. The Range<T> interface represents a bounded or unbounded range. (From now on, range, span and interval are used interchangeably, but docs only use "range")<br>
</blockquote></div>