> From: "Rafael Winterhalter"
> To: "Remi Forax"
> Cc: "core-libs-dev" , "joe darcy"
>
> Sent: Tuesday, January 21, 2025 10:17:35 AM
> Subject: Re: Factory methods for SequencedSet and SequencedMap
> Wouldn't this already be po
On 1/17/2025 5:49 PM, David Alayachew wrote:
It definitely helps.
I guess my next question is, there is no bridge method, which is why
this fails. Why not add a bridge method? What is stopping Java from
doing this?
The default response to the question "Should we fundamentally change how
y"
> *To: *"core-libs-dev"
> *Sent: *Friday, January 17, 2025 6:30:40 PM
> *Subject: *Re: Factory methods for SequencedSet and SequencedMap
>
> On 1/16/2025 11:26 PM, Rafael Winterhalter wrote:
>
>
> Would it even be possible to change the return types of Set.of(...) and
> Map.of(...) without breaking binary compatibility?
>
>
> In short, no.
>
>
> [...]
>
>
> -Joe
>
>
> Rémi
>
>
than adding
SequenceSet/SequenceMap so it's a big if, but it may happen in the future.
Rémi
> From: "joe darcy"
> To: "core-libs-dev"
> Sent: Friday, January 17, 2025 6:30:40 PM
> Subject: Re: Factory methods for SequencedSet and SequencedMap
> On
That's the missing link. Thanks Archie.
Man, I still don't get the decision-making in 1995 to make it not
overridable. It is what it is.
On Sat, Jan 18, 2025, 10:06 AM Archie Cobbs wrote:
> On Fri, Jan 17, 2025 at 7:50 PM David Alayachew
> wrote:
>
>> I guess my next question is, there is no b
On Fri, Jan 17, 2025 at 7:50 PM David Alayachew
wrote:
> I guess my next question is, there is no bridge method, which is why this
> fails. Why not add a bridge method? What is stopping Java from doing this?
>
In Java class files it's possible to have two methods that differ only in
their return
It definitely helps.
I guess my next question is, there is no bridge method, which is why this
fails. Why not add a bridge method? What is stopping Java from doing this?
And to be clear, it is obvious to me that SewuencedSet.of is the right
answer. I am just trying to understand the point you rai
On 1/17/2025 5:00 PM, David Alayachew wrote:
Thanks for the corrections folks. I was thinking from the perspective
of LSP. I now see that there is the performance perspective to
consider too.
Now that said, I don't understand your comment Joe Darcy. Could you
explain it in more detail?
S
Thanks for the corrections folks. I was thinking from the perspective of
LSP. I now see that there is the performance perspective to consider too.
Now that said, I don't understand your comment Joe Darcy. Could you explain
it in more detail?
My initial pick up of your comment is that, the paramet
On 1/16/2025 11:26 PM, Rafael Winterhalter wrote:
Would it even be possible to change the return types of Set.of(...)
and Map.of(...) without breaking binary compatibility?
In short, no.
The methods in question are *static* methods. Switching to covariant
overrides with more precise return t
On Fri, Jan 17, 2025 at 9:22 AM Ethan McCue wrote:
> Just so there are some strawman arguments against:
>
To pile on...
If I go to a restaurant and order a hamburger and they bring me a
cheeseburger and also charge me extra for it, I'm going to complain!
A Set and a SequencedSet are two differ
Just so there are some strawman arguments against:
* Does altering Set.of to maintain order increase its memory footprint? If
the answer is yes, does that matter? If the answer is no, is there a new
standalone collection type to add?
SetThatIsOrderedInTheSameMannerAsPythonsSetIsOrderedAndThusHasNo
Sure, changing the return type to a more specialized type is never a
problem. And even if it was, the explicit documentation on those factory
methods was that the actual implementation is subject to change, and should
not be depended on.
Also, your argument about iteration order doesn't make sense
Would it even be possible to change the return types of Set.of(...) and
Map.of(...) without breaking binary compatibility?
I also think that the randomization of Set.of(...) and Map.of(...) is a
good property as it uncovers bugs early if one relies on iteration order.
This especially since those m
I should also add, the documentation went out of their way to specify that
iteration order is unspecified.
Also, I see Rémi's comment, but that's even more unconvincing to me.
Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper
limit of that Java max file size limit thing. You
I guess let me ask the obvious question.
Chesterton's fence -- why wasn't this done before? I refuse to believe that
this idea wasn't thought up years ago, which leads me to believe there was
a reason that it hasn't been done.
Is there any way we can look this up in the bug database or something?
Having the result Map.of and Set.of preserve the insertion order would
often be convenient.
More often than not programs iterate over the contents of a maps and
sets at some point. For example to present the values in a GUI, for
serialisation, or even for error printouts. In all those cases ha
> From: "Rafael Winterhalter"
> To: "core-libs-dev"
> Sent: Thursday, January 16, 2025 8:13:17 AM
> Subject: Factory methods for SequencedSet and SequencedMap
> Hello,
Hello,
> I am happily taking SequencedSet and SequencedMap into use, but one
> inconvenience I encounter is the lack of facto
18 matches
Mail list logo
