As part of the redesigning process , I am researching whether or not there are use cases that require asserting that the range is exactly half-bounded. This is important because I plan to switch to BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime checks: Here is what I gathered for now.
- *Date/Time Handling (Historical or Forecast Data)*: When dealing with events that started at a specific time but have no known end (e.g., open-ended employment contracts or ongoing subscriptions) - *Stream Processing (Real-time Event Streams)*: In real-time systems, you might process data that has a start time but no defined end, such as monitoring a live video feed or logging system. The range is bounded at the start and unbounded at the end as more data will continuously arrive. - *Data Pagination (Fetch Until Condition)*: When implementing pagination, sometimes you might want to fetch items starting from a specific index up to an unbounded limit (e.g., fetching all items after a certain point until memory runs out or a condition is met). - *Auditing and Monitoring*: In systems where audit trails or logging data should capture all events after a certain point (bounded start) with no foreseeable end (unbounded end), such as monitoring changes to records in a database starting from a fixed timestamp. - *Scientific or Statistical Ranges*: When modeling physical systems or statistical ranges, you might want to capture measurements that begin at a known threshold but theoretically have no upper or lower bound. For example, recording temperature data starting at absolute zero and increasing without any known upper limit. - *Inventory or Resource Allocation*: Resource allocation policies, such as those for virtual machines, may be based on known minimum allocation thresholds but have flexible or unbounded resource caps, depending on availability. I am writing to ask whether anyone who worked with such systems could confirm/deny that those are real use cases. If so, would it be satisfying enough to assert one-way unboundness with instanceof checks, i.e. range instanceof UnboundedEndRange && !(range instanceof UnboundedStartRange). Would appreciate any feedback. Best regards On Tue, Sep 24, 2024 at 12:02 AM Olexandr Rotan <rotanolexandr...@gmail.com> wrote: > But do those two use cases really need an abstraction? Is there really >> value in a Range interface? >> Given the two classes above, which are IMO candidates for the JDK, they >> work fine as isolated value types without a generalized abstraction. > > > 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. > > 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. > > > 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. > > 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. > > > 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. > > 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. > > PS: Regarding chronological ranges specifically, this was my motivation in > the first place ( > https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125271.html)..I > 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. > > On Mon, Sep 23, 2024 at 11:24 PM Stephen Colebourne <scolebou...@joda.org> > wrote: > >> I've always found the generic concept of a "range" tricky to express >> in a sensible API. When authoring Joda-Time and java.time I avoided it >> as much as possible. >> >> ThreeTen-Extra has two classes - Interval and LocalDateRange - which >> cover the two main use cases. >> >> https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/package-summary.html >> >> But do those two use cases really need an abstraction? Is there really >> value in a Range interface? >> Given the two classes above, which are IMO candidates for the JDK, >> they work fine as isolated value types without a generalized >> abstraction. >> >> 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. (ie. some language designs are built around ranges as a >> first class concept, but Java isn't, and I have doubts that it would >> be a good fit to try and pivot that way now.) In particular, I >> struggle with a generified Range type - it just "feels wrong" to me. >> >> 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. And that is before you consider >> discrete versus continuous. >> Stephen >> >> >> On Sun, 22 Sept 2024 at 20:02, Olexandr Rotan >> <rotanolexandr...@gmail.com> wrote: >> > >> > 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: >> https://github.com/openjdk/jdk/pull/21122, and PR text: >> > >> > 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") >> >
