On 20/05/2021 08:35, dfranken@gmail.com wrote:
I also think the proposal of Stuart is reasonable though, but it seemed
to me that we had reached some sort of impasse in this discussion. As
Remi points out, we have (default) methods which sometimes throw
exceptions when they are implemented
Dear Brian,
I understand this would be a massive undertaking.
Still, the date-time library was a mess before Java 8 and it has been
rewritten and found its way to most other libraries.
So while I understand this isn't going to be done any time soon, my
only question was whether it had been
Has it ever been conceived to create an entire new API like how it was
done for Dates and Times? Obviously this would be a massive
undertaking, but it seems to me we've just about reached the limits of
how far we can stretch the current API.
"This code is a mess, we should throw it away and
+0200, fo...@univ-mlv.fr wrote:
> - Mail original -
> > De: "Anthony Vanelverdinghe"
> > À: "Remi Forax"
> > Cc: "Stuart Marks" , "core-libs-dev"
> >
> > Envoyé: Jeudi 13 Mai 2021 21:18:22
>
- Mail original -
> De: "Anthony Vanelverdinghe"
> À: "Remi Forax"
> Cc: "Stuart Marks" , "core-libs-dev"
>
> Envoyé: Jeudi 13 Mai 2021 21:18:22
> Objet: Re: [External] : Re: ReversibleCollection proposal
> Hi Rémi
>
Hi Stuart
Will EnumSet also be updated to implement ReversibleSet? Or will it be updated
to implement NavigableSet [1] independently of this enhancement?
I'd also like to propose adding `ReversibleSet::of` factory methods. This is
something I miss having on SortedSet occasionally, but
Hi Rémi
The discussion "new types? or new default methods?" is indeed a valid one. In
fact, I think this choice has already been made once in favor of a default
method, when adding `List::sort` was chosen over adding `SortedList` (though I
imagine that choice was a no-brainer).
In this case I
- Mail original -
> De: "Peter Levart"
> À: "Stuart Marks"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 12 Mai 2021 08:28:07
> Objet: Re: [External] : Re: ReversibleCollection proposal
> On 5/12/21 2:55 AM, Stuart Marks wrote:
>> As
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 12 Mai 2021 07:27:51
> Objet: Re: [External] : Re: ReversibleCollection proposal
>>> I'm certain that uses of RC/RS will be rare i
On 5/12/21 2:55 AM, Stuart Marks wrote:
As you point out, add() is kind of like addLast(), except without the
reordering semantics for LinkedHashSet. And reversed().add() is a
roundabout way of saying addFirst() -- also without the reordering
semantics for LinkedHashSet. I think most
I'm certain that uses of RC/RS will be rare in the beginning, because they will
be
new, and people won't be familar with them. And then there will the people who
say
"I can't use them because I'm stuck on JDK 11 / 8 / 7 / 6 " It was the same
thing with lambdas and streams in Java 8, with
On 5/1/21 7:36 AM, Peter Levart wrote:
On 4/30/21 9:25 PM, Stuart Marks wrote:
So I think we're stuck with void-returning add{First,Last} methods.
Have you thought of perhaps not adding them at all?
Collection.add() for:
List(s) - behaves the same as addLast()
LinkedHashSet - behaves
- Mail original -
> De: "Peter Levart"
> À: "Remi Forax" , "dfranken jdk"
> Cc: "Stuart Marks" , "core-libs-dev"
>
> Envoyé: Mardi 11 Mai 2021 13:44:08
> Objet: Re: [External] : Re: ReversibleCollection proposal
>
on, 2021-05-10 at 12:22 +0200, fo...@univ-mlv.fr wrote:
- Mail original -
De: "dfranken jdk"
À: "Remi Forax" , "Stuart Marks"
Cc: "core-libs-dev"
Envoyé: Dimanche 9 Mai 2021 12:13:58
Objet: Re: [External] : Re: ReversibleCollection proposal
When I t
- Mail original -
> De: "dfranken jdk"
> À: "Remi Forax"
> Cc: "Stuart Marks" , "core-libs-dev"
>
> Envoyé: Mardi 11 Mai 2021 08:45:15
> Objet: Re: [External] : Re: ReversibleCollection proposal
> Dear mr. Forax,
Hi Dave,
t; - Mail original -
> > De: "dfranken jdk"
> > À: "Remi Forax" , "Stuart Marks"
> >
> > Cc: "core-libs-dev"
> > Envoyé: Dimanche 9 Mai 2021 12:13:58
> > Objet: Re: [External] : Re: ReversibleCollection proposa
- Mail original -
> De: "dfranken jdk"
> À: "Remi Forax" , "Stuart Marks"
> Cc: "core-libs-dev"
> Envoyé: Dimanche 9 Mai 2021 12:13:58
> Objet: Re: [External] : Re: ReversibleCollection proposal
> When I thought a
Forax"
> > Cc: "core-libs-dev"
> > Envoyé: Mercredi 5 Mai 2021 02:00:03
> > Objet: Re: [External] : Re: ReversibleCollection proposal
>
> > On 5/1/21 5:57 AM, fo...@univ-mlv.fr wrote:
> > > I suppose the performance issue comes from the fact that
> >
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 5 Mai 2021 02:00:03
> Objet: Re: [External] : Re: ReversibleCollection proposal
> On 5/1/21 5:57 AM, fo...@univ-mlv.fr wrote:
>&g
On 5/1/21 5:57 AM, fo...@univ-mlv.fr wrote:
I suppose the performance issue comes from the fact that traversing a
LinkedHahSet is slow because it's a linked list ?
You can replace a LinkedHashSet by a List + Set, the List keeps the values in
order, the Set avoids duplicates.
Using a
The line of discussion here was introduced by Remi, who was making an argument of
the form "introducing a type cannot solve this particular problem, therefore,
introducing a new type is not useful at all." I was providing an example of where
the new type is useful as a method parameter. That's
On 4/30/21 9:25 PM, Stuart Marks wrote:
So I think we're stuck with void-returning add{First,Last} methods.
Have you thought of perhaps not adding them at all?
Collection.add() for:
List(s) - behaves the same as addLast()
LinkedHashSet - behaves the same as addLast()
Deque - behaves
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Samedi 1 Mai 2021 00:42:10
> Objet: Re: ReversibleCollection proposal
>> You did not really answer to the real question, why should i
It sounds like the items processing maintainer would be looking for
OrderedCollection and might or might not find ReversibleCollection. :-)
I suspect you would agree that OrderedCollection by itself is too weak to
justify being a type. It’s basically Iterable with the extra bit that the
You did not really answer to the real question, why should i use
ReversibleCollection instead of a Collection as parameter.
You said that it's a better type because you can not send a HashSet, but as i
said, sending a HashSet of 0 or 1 element is perfectly valid.
For me, we are not far
OK, I think we can wrap up this portion of the thread.
As the proposal stands, it has add{First,Last} returning void instead of some useful
value. For SortedSet and for LinkedHashMap's views, these throw UOE. Can we do better?
Collection has add(), Deque has add{First,Last} and
On 4/28/21 7:19 AM, Stuart Marks wrote:
On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
wrote:
Now just some of my thoughts about the proposal:
- SortedSet.addFirst/.addLast - I think an operation that would be used
in situations
Hi,
(I think the first version of this message never went through, so here it
goes just in case)
I just read quickly the proposal and it made me think about another common
issue. I wonder if we could tackle it as well.
I will call it the "find the first element when there is only one" problem.
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Vendredi 23 Avril 2021 08:56:53
> Objet: Re: ReversibleCollection proposal
>> An API can not use ReversibleCollection as parameter before
- Mail original -
> De: "Stuart Marks"
> À: "Peter Levart"
> Cc: "core-libs-dev" , "Stephen Colebourne"
>
> Envoyé: Mercredi 28 Avril 2021 02:04:22
> Objet: Re: ReversibleCollection proposal
> On 4/27/21 2:25 AM, Peter Le
On 4/28/21 2:04 AM, Stuart Marks wrote:
Binary compatibility is important. And I guess there is a variant of
the proposal that includes ReversibleCollection and ReversibleSet and
is binary compatible.
Yes, the source incompatibilities with the types seem to involve type
inference (e.g.,
On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
wrote:
Now just some of my thoughts about the proposal:
- SortedSet.addFirst/.addLast - I think an operation that would be used
in situations like: "I know this element should always be
On 4/27/21 2:25 AM, Peter Levart wrote:
Right, I'm persuaded. Now if only the problems of transition to the usage of new
type that Remi is worried about were mild enough. Source (in)compatibility is not
that important if workarounds exist that are also backwards source compatible so
that
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
wrote:
> Now just some of my thoughts about the proposal:
>
> - SortedSet.addFirst/.addLast - I think an operation that would be used
> in situations like: "I know this element should always be greater than
> any existing element in the set and
Hi,
Not sure if this will end up in the right mailing list thread but let's see.
I just read quickly the proposal and it made me think about another common
issue. I wonder if we could tackle it as well.
I will call it the "find the first element when there is only one" problem.
It happens on
On 4/27/21 5:50 AM, Stuart Marks wrote:
On 4/25/21 11:09 AM, Peter Levart wrote:
When making this proposition, I was only thinking of how to enable
new yet-nonexistent operations on collections that have order / are
reversible and that the code calling these methods would already
knows
On 4/25/21 11:09 AM, Peter Levart wrote:
When making this proposition, I was only thinking of how to enable new
yet-nonexistent operations on collections that have order / are reversible and that
the code calling these methods would already knows that it is dealing with ordered /
reversible
On 4/23/21 8:33 AM, Stuart Marks wrote:
This is what I intended anyway, ie that its OK for "first" to work on
an unordered collection, just that addFirst() has very weak semantics
wrt first-ness.
"Ensures that this collection contains the specified element(optional
operation). This has the
On Fri, 23 Apr 2021 at 07:33, Stuart Marks wrote:
> On 4/22/21 8:36 AM, Stephen Colebourne wrote:
> Having these methods on Collection could lead to a situation where calling
> addFirst
> and then getFirst might result in getFirst returning a different element from
> what
> was passed to
An API can not use ReversibleCollection as parameter before all the
implementations of Collection that have an ordering are updated to implement
ReversibleCollection instead of Collection.
By example, if I add a method
public void foo(ReversibleCollection c)
in my library, people that want
On 4/22/21 8:36 AM, Stephen Colebourne wrote:
On Thu, 22 Apr 2021 at 13:58, Remi Forax wrote:
I would like to preserve the invariant that, when calling a method on a
Collection/iterator, an UnsupportedOperationException only occurs when trying
to mutate that collection.
If we are ok with
On Thu, 22 Apr 2021 at 13:58, Remi Forax wrote:
> I would like to preserve the invariant that, when calling a method on a
> Collection/iterator, an UnsupportedOperationException only occurs when trying
> to mutate that collection.
> If we are ok with that, this means that addFirst can not be a
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 21 Avril 2021 19:38:23
> Objet: Re: ReversibleCollection proposal
> On 4/19/21 4:05 PM, fo...@univ-mlv.fr wrote:
>>> * There's
- Mail original -
> De: "Stephen Colebourne"
> À: "core-libs-dev"
> Envoyé: Jeudi 22 Avril 2021 00:14:10
> Objet: Re: ReversibleCollection proposal
> On Wed, 21 Apr 2021 at 18:39, Stuart Marks wrote:
>> The value being provided here i
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 21 Avril 2021 20:53:25
> Objet: Re: [External] : Re: ReversibleCollection proposal
> On 4/19/21 2:01 PM, Remi Forax wrote:
>> - M
On 4/22/21 12:14 AM, Stephen Colebourne wrote:
public interface Collection {
default E getFirst() { return iterator().next(); }
Searching for ".iterator().next()" yields 74 matches in JDK sources...
Peter
On Wed, 21 Apr 2021 at 18:39, Stuart Marks wrote:
> The value being provided here is that the ReversibleCollection interface
> provides a
> context within which specs no longer need to hedge about "if the collection
> has an
> ordering". APIs that produce or consume ReversibleCollection no
On 4/19/21 2:01 PM, Remi Forax wrote:
- Mail original -
Thinking a little bit about your proposal,
introducing an interface right in the middle of a hierarchy is not a backward
compatible change
(you have an issue when the compiler has to use the lowest upper bound).
By example
On 4/19/21 4:05 PM, fo...@univ-mlv.fr wrote:
* There's a useful clump of semantics here, combined with sensible operations
that
rely on those semantics. There are a lot of places in the spec where there is
hedging of the form "if the collection has an ordering, then... otherwise the
- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Lundi 19 Avril 2021 17:41:11
> Objet: Re: ReversibleCollection proposal
> On 4/17/21 9:49 AM, Remi Forax wrote:
>> I think the analy
- Mail original -
> De: "Stuart Marks"
> À: "core-libs-dev"
> Envoyé: Vendredi 16 Avril 2021 19:40:55
> Objet: ReversibleCollection proposal
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking f
On 4/17/21 9:49 AM, Remi Forax wrote:
I think the analysis is spot on but I don't think the proposed solution is the
right one.
Introducing a new interface (two in this case) has a really huge cost and in
this case, i've trouble to see why i will want to write a method that takes a
On 4/18/21 9:51 AM, Peter Levart wrote:
public interface Collection {
default Collection reversed() { return this; }
default void addFirst(E e) { throw new
UnsupportedOperationException(); }
default void addLast(E e) { throw new
UnsupportedOperationException(); }
On 4/18/21 9:51 AM, Peter Levart wrote:
public interface Collection {
default Collection reversed() { return this; }
default void addFirst(E e) { throw new
UnsupportedOperationException(); }
default void addLast(E e) { throw new
UnsupportedOperationException(); }
A word for Remi's concern...
While it is good that List (and SortedSet and Deque) extend
ReversibleCollection in the proposal, it is a pity the same is not true
for Set and Queue. If Set and Queue could also be
ReversibleCollection(s), then we would not need ReversibleCollection at
all and
Hello, Remi!
On Sat, Apr 17, 2021 at 11:50 PM Remi Forax wrote:
> Introducing a new interface (two in this case) has a really huge cost and in
> this case, i've trouble to see why i will want to write a method that takes a
> ReversibleCollection as parameter, ReversibleCollection as a type
> Adding a REVERSIBLE characteristic to spliterators is easy enough
Actually not. There are already tons of delegating spliterators in the
wild, and many of them delegate characteristics in one or another way.
Usually, it's like 'copy all the source characteristics except A and
B' (i.e.
> I'm also concerned about conflicts over the other method names; something
> like addFirst() is a pretty obvious method to add to a custom List
> implementation. I haven't seen any, but that doesn't mean there aren't any.
>
> s'marks
The getFirst() and getLast() methods will have
Hi, Stuart, happy to help.
I took a look at Groovy and Kotlin. Groovy has reverse() [1] and Kotlin has
reversed() [2] and asReversed() [3] and reverse() [4]. I’m not quite familiar
enough with Kotlin to know whether the reversed() method will collide.
[1]
On 4/17/21 4:49 AM, Tagir Valeev wrote:
Great proposal, thanks!
It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.
Thanks! And thanks for making that proposal a year
On 4/17/21 2:48 AM, Stephen Colebourne wrote:
On Fri, 16 Apr 2021 at 18:41, Stuart Marks wrote:
This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send
On 4/16/21 3:06 PM, Donald Raab wrote:
We should be cautious when adding new APIs to existing interfaces. There may be
libraries which extend JDK types and already have reversed(), toReversed() or
asReversed() APIs and corresponding interfaces.
There are OrderedIterable and
- Mail original -
> De: "Stuart Marks"
> À: "core-libs-dev"
> Envoyé: Vendredi 16 Avril 2021 19:40:55
> Objet: ReversibleCollection proposal
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking f
Adding a REVERSIBLE characteristic to spliterators is easy enough, and
as you say, many useful sources can easily provide an efficient reverse
operation. Filtering and mapping can preserve reversibility. The real
question is what to do if someone calls reverse() on a non-reversible
stream.
Great proposal, thanks!
It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.
Some people really want to reverse Streams as well. E. g., the
corresponding StackOverflow question
On Saturday, April 17, 2021 11:48 CEST, Stephen Colebourne
wrote:
> On Fri, 16 Apr 2021 at 18:41, Stuart Marks wrote:
> > This is a proposal to add a ReversibleCollection interface to the
> > Collections
> > Framework. I'm looking for comments on overall design before I work on
> > detailed
On Fri, 16 Apr 2021 at 18:41, Stuart Marks wrote:
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on
> detailed
> specifications and tests. Please send such comments as replies on this email
>
Hi Stuart,
We should be cautious when adding new APIs to existing interfaces. There may be
libraries which extend JDK types and already have reversed(), toReversed() or
asReversed() APIs and corresponding interfaces.
There are OrderedIterable and ReversibleIterable interfaces and asReversed()
This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send such comments as replies on this email thread.
Here's a link to a draft PR that contains the code
69 matches
Mail list logo
