Text copied from PR draft since no one really goes through 2-month old
drafts ;)
For anyone wondering what's up with this PR, I have decided to take a
little break from coding itself and focus on the more fundamental part of
ranges. Most of the time I was thinking about the range lifecycle, how th
>
> but I also don't sense people beating down the doors for that (even if the
> language had range literals, like `0..<100`).
True, that what I was thinking also: "is iteration over numeric range is so
important to challenge general versatility of API?", but
for (int j=index; j (start, end) and
Sorry for the not-good news, but I'm not too surprised. Computational
domains like "32 bit integers" seem like they should have a lot in
common with algebraic structures like groups and rings, but when you
start poking at them, the compromises we make to fit them into hardware
registers start
Researching the of deriving some iterable representations from ranges, and
I am not here with the good news.
Unlike range algebra and boolean operations, which generalize
extremely well, iterability of ranges... Well, it's safe to say it
doesn't generalize at all. Analyzing key features people exp
I have another example: I have a datatype that represents a region of an audio
track, for example, one tune in a medley of tunes. I allow the region to
specify both a start and end time, but the end time is optional (and mostly not
used). When the end time is not specified, the region ends at the
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 ga
>
> 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 y
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 shap
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", "
On Sun, Sep 22, 2024 at 2:03 PM Olexandr Rotan
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:
Hello!
Thanks for your comments, they are valuable to me. I indeed intended to
make Range immutable, if you noticed, in potential methods I listed
extendTo and shrinkTo, which is kind of modified with-ers. But, it's indeed
better to convert range to class and expose some methods to create bounded
a
11 matches
Mail list logo
