On 7/19/14 2:04 AM, Remi Forax wrote:
You can combine these 2 approachesi using a Ruby like builder approach with a
lambda,
which provide a builder object (so static method call are replaced by instance
method call) avoiding the creation of too many entry objects
Map.of(b -> b
.entry(k
On 7/18/14 4:41 PM, David M. Lloyd wrote:
On 07/18/2014 06:36 PM, Stuart Marks wrote:
Map.of()
.add(k0, v0)
.add(k1, v1)
...
.add(kN, vN);
this would result in O(N^2) performance and space allocation, though
most of the allocated space is garbage.
Adding
On 07/19/2014 01:36 AM, Stuart Marks wrote:
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I
>
> I don't think we want to have a Map.add(k,v) instance method (or default
> method) for immutable maps or for constructing them.
>
> For a fast, compact, immutable map implementation, the only way to implement
> Map.add() would be to copy the entire contents plus the additional pair into
>
On 07/18/2014 06:36 PM, Stuart Marks wrote:
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I d
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I don't think we want to have a Map.add(k,v) ins
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
> A .with(k, v) to create a new immutable map with an extra pair.
>
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
Michael Kay
Saxonica
A .with(k, v) to create a new immutable map with an extra pair.
--Max
On Jul 18, 2014, at 16:11, Michael Kay wrote:
>>
>> Well, Remi had proposed raising the limit. Suppose we offered 7 key-value
>> pairs instead of 5. Would you then complain about having to rewrite your
>> code if you had t
>
> Well, Remi had proposed raising the limit. Suppose we offered 7 key-value
> pairs instead of 5. Would you then complain about having to rewrite your code
> if you had to add an 8th entry to the map?
Yes, I would. In fact, the higher you make the limit, the bigger the surprise
when I find
On 17/07/2014 22:56, Stuart Marks wrote:
On 7/17/14 12:46 AM, Tom Hawtin wrote:
I note that with the basic proposal, HashSet.of and indeed
NavigableSet.of still
work. They just do the wrong thing.
I should have made more clear in the JEP that the proposed APIs are
static methods on the List/Ma
Hi Dan, thanks for the feedback.
On 7/17/14 10:40 AM, Dan Smith wrote:
The motivation section ought to more directly survey what we have now:
- Collections.emptyList/emptySet/emptyMap
- Collections.singletonList/singleton/singletonMap
- Arrays.asList
- EnumSet.of (varargs, plus some overloads)
-
On 7/17/14 10:17 AM, Steven Schlansker wrote:
This is fantastic, I think a large number of developers will cheer as more and
more of Guava
makes it into core libs :)
Great!
One thing I notice is that you take a lot of care to not specify how the Map or
Set will be implemented.
This could
On 7/17/14 12:46 AM, Tom Hawtin wrote:
I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still
work. They just do the wrong thing.
I should have made more clear in the JEP that the proposed APIs are static
methods on the List/Map/Set interfaces, not default methods. Th
On 7/17/14 12:21 AM, Michael Kay wrote:
Set.of() and List.of() look very attractive; Map.of() looks very ugly.
The proposed Map.of() API offends our sensibilities as programmers, because of
its repetition and its lack of generality. I think that's what you mean by
"ugly". There is a indeed
The motivation section ought to more directly survey what we have now:
- Collections.emptyList/emptySet/emptyMap
- Collections.singletonList/singleton/singletonMap
- Arrays.asList
- EnumSet.of (varargs, plus some overloads)
- Stream.empty and Stream.of (singleton plus varargs)
- Constructors that,
On Jul 16, 2014, at 5:46 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this draft JEP for Convenience Factory Methods for Collections:
>
>https://bugs.openjdk.java.net/browse/JDK-8048330
>
> Brief background: several times over the years there have been proposals to
> add "collecti
On 07/17/2014 04:05 AM, Paul Benedict wrote:
Regarding why you didn't choose a straight vararg solution, I prefer
you do allow any number of key/values as long as you throw an
exception if the array is not an even sized.
You can not extract/infer the type of the key and the type of the value
On 17 Jul 2014, at 08:21, Michael Kay wrote:
> Set.of() and List.of() look very attractive; Map.of() looks very ugly.
>
> I would much prefer to write something like
>
> Map.of(
> Map.pair(key, value),
> Map.pair(key, value),
> Map.pair(key, value)
> );
>
Another style that would work for
I note that with the basic proposal, HashSet.of and indeed
NavigableSet.of still work. They just do the wrong thing.
Tom
Set.of() and List.of() look very attractive; Map.of() looks very ugly.
I would much prefer to write something like
Map.of(
Map.pair(key, value),
Map.pair(key, value),
Map.pair(key, value)
);
and have no limit on the number of pairs. (Don't care how it works
internally...)
The last thing
Regarding why you didn't choose a straight vararg solution, I prefer you do
allow any number of key/values as long as you throw an exception if the
array is not an even sized.
Cheers,
Paul
On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks
wrote:
> On 7/16/14 6:03 PM, Remi Forax wrote:
>
>> On 07/
On 7/16/14 6:03 PM, Remi Forax wrote:
On 07/17/2014 02:46 AM, Stuart Marks wrote:
Please review this draft JEP for Convenience Factory Methods for Collections:
https://bugs.openjdk.java.net/browse/JDK-8048330
Brief background: several times over the years there have been proposals to
add "
On 07/17/2014 02:46 AM, Stuart Marks wrote:
Hi all,
Please review this draft JEP for Convenience Factory Methods for
Collections:
https://bugs.openjdk.java.net/browse/JDK-8048330
Brief background: several times over the years there have been
proposals to add "collection literals" to th
23 matches
Mail list logo
