Range API

[Olexandr Rotan]

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/1429ff9b/attachment.htm>