Range API

[Olexandr Rotan]

Hello, Markus.

API is not limited to timespans. It was a sample implementation for Range
interface back when it was not refactored into abstract class, which, by
the way, was removed from PR as for now.

My initial motivation was to provide a range for date and time values, so I
based general shape pretty heavily on the date time libraries.
Nevertheless, as you might see, API is type-agnostic, and one of the goals
is to make ranges specializable for different types (although this would
require additional research)

Best regards

On Mon, Sep 23, 2024 at 9:10 PM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> Hello! Thanks for your comments
>
> The start() and end() be should be specifiable as either inclusive or
>> exclusive, otherwise open bounds are not possible. For example, how would
>> one express the range of all Strings strictly less than "zzz"? (note every
>> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
>> "zzz"). This is why for example NavigableSet.subSet() has parameters for
>> that.
>
>
> This has been addressed by modifying API today, now all types of ranges
> support both exclusive and inclusive bounds.
>
> I've never encountered a negative range and am skeptical that it would
>> actually be useful. What's an example of a real-world use case? I don't see
>> how they would help diagrams visualization other than maybe saving you a
>> boolean, i.e., you could just use the normal range and draw the arrow the
>> other way.
>
>
> I guess this was my fault as I chose the wrong design perspective. I have
> already commented on this pull request. Basically, I have some physics
> background and I used to view ranges as vectors instead of scalars, so it
> was just fluent to me in some way to allow negative ranges. Anyway, now
> that I have received unanimous feedback regarding the requirement of
> inclusive/exclusive bounds, and having both negative ranges and
> different types of bounds just blows up the implementations, so negative
> ranges were dropped.
>
> In my experience, when you work with ranges you often also need to work
>> with sets of ranges. If we had a Range class then it would be natural to
>> also have a RangeSet class as well with union, intersection, difference,
>> and ordered iteration operations, etc.
>
>
> That is true. I saw high demand on it in comments, so now this is my
> second priority in the list to develop Union type and common supertype for
> it and Range (after making bounds compile-time checked so users don't have
> to suffer exceptions if range does not have bound).
>
> You are restricting to domains that implement Comparable, but this limits
>> usefulness. For example, byte[] arrays are often ordered lexicographically
>> as unsigned values and we want to work with ranges of byte[] arrays. It
>> would be more general to allow supplying a Comparator (if needed, otherwise
>> null). Then you would also want to expose this using a comparator() method
>> (like SortedSet does). Note that Guava does not allow providing a
>> Comparator so they voted the other way on this.
>
>
> This would make range arithmetics tangled. What if you intersect ranges
> with different comparators? What is the behaviour of gap and difference?
> What if you want to unionize them? This most likely will lead to breach of
> Union contract, which guarantees that ranges do not overlap. Even if users
> pass a comparator to every operation, what will guarantee that end > start
> for this comparator for both ranges? There are a lot of issues with this
> initiative.
>
> Guava has addressed this same problem; their approach worth reviewing:
>> https://github.com/google/guava/wiki/RangesExplained
>
>
> Thanks. I will look into it for references. To my shame, I haven't looked
> into guava when designing the API, so this will be really useful.
>
> Best regards
>
> On Mon, Sep 23, 2024 at 5:10 AM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Sun, Sep 22, 2024 at 2:03 PM Olexandr Rotan <
>> rotanolexandr842 at 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.
>>>
>>
>> A few comments...
>>
>> Guava has addressed this same problem; their approach worth reviewing:
>> https://github.com/google/guava/wiki/RangesExplained
>>
>> You are restricting to domains that implement Comparable, but this limits
>> usefulness. For example, byte[] arrays are often ordered lexicographically
>> as unsigned values and we want to work with ranges of byte[] arrays. It
>> would be more general to allow supplying a Comparator (if needed, otherwise
>> null). Then you would also want to expose this using a comparator() method
>> (like SortedSet does). Note that Guava does not allow providing a
>> Comparator so they voted the other way on this.
>>
>> The start() and end() be should be specifiable as either inclusive or
>> exclusive, otherwise open bounds are not possible. For example, how would
>> one express the range of all Strings strictly less than "zzz"? (note every
>> element in the infinite sequence "zzy", "zzyy", "zzyyy", ...  is less than
>> "zzz"). This is why for example NavigableSet.subSet() has parameters for
>> that.
>>
>> I've never encountered a negative range and am skeptical that it would
>> actually be useful. What's an example of a real-world use case? I don't see
>> how they would help diagrams visualization other than maybe saving you a
>> boolean, i.e., you could just use the normal range and draw the arrow the
>> other way.
>>
>> In my experience, when you work with ranges you often also need to work
>> with sets of ranges. If we had a Range class then it would be natural to
>> also have a RangeSet class as well with union, intersection, difference,
>> and ordered iteration operations, etc.
>>
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240923/6a055a97/attachment-0001.htm>