list literal gotcha and suggestion

[Reinier Zwitserloot]

Stephen - adding various toX methods to the as yet undefined but  
immutable list subtype that list literals return is an excellent idea.  
The notion of using ExplicitType.of() to create mutables, and list  
literals + an optional method call to create immutables is quite  
flexible, and while unfortunately not obvious from a casual glance (in  
that neither form explicitly includes the characters 'immutable' or  
'mutable' or some sort of variant thereof), its very consistent, and  
thus one may reasonably expect even beginning java programmers to pick  
up on the pattern.

One change that may be better is to replace the 'of' method from a  
varargs line to a literal - a wrapper for the copy constructor. In  
practice it just boils down to adding 2 braces so you get your list  
literal, and it would be better for HashMap, as trying to do a Map  
literal via a static method isn't all that nice. (You can do it -  
google collections API does it, sort of - but it's not very elegant).  
There's still a point to duplicating the functionality: Eliminate the  
generics (even if in java7 you can get away with the diamond operator,  
that makes things look a bit perly). Switching to this standard also  
throws a bone to the alternative collections APIs out there, as they  
can copy the syntax - e.g. to create a (mutable) ArrayList, you'd go:  
ArrayList.of({1, 2, 3}); and to create a new ImmutableList (google  
collections API), you'd have to write ImmutableList.of({1, 2, 3}); -  
so the general rule is then: To create any collections literal, write:  
Type.of(list literal);

NB: Gene, you're trying to argue that a _literal_ set is going to make  
some sort of speed difference compared to a a_literal_ list. That  
notion is frankly ridiculous. You also lost track of the first rule of  
discussing speed: Test it first. So, go ahead. Benchmark a bunch  
of .contains() calls on a list and a set with the same items in it,  
both with say, 20 items in them (we are talking about literals, after  
all. I don't think anyone is seriously considering sticking hundreds  
of lines of code in a .java file to store constant data!) -  on my own  
machine Lists are less than a factor of 2 slower. For about 7 items  
and down, lists are in fact faster. Also, just in case someone IS  
tempted to write such a large collections literal: For such a large  
literal, the added burden of wrapping the literal in a "new  
HashSet<>()" or sticking a ".toSet();" at the end seems trivial.

I think the 'set literals are rare' seem to have it, so I repeat my  
plea to the set literal fans: Give us some proof they aren't rare.  
Given that set literals cause so much pain, the burden is clearly on  
the supporters of a set literal to prove why we need them.

  --Reinier Zwitserloot



On 2009/29/09, at 21:07, Gene Ray wrote:

> "Rare"?
>
> In my experience, Sets are not rare in well-written code; they're  
> only rare in code where for whatever reason the developer has  
> refused to use them, and instead expends effort and CPU time  
> iterating through an array or ArrayList to achieve the equivalent  
> functionality.  Encouraging this sort of behavior further by  
> including only Lists in the new syntax is not a good plan.
>
>
>
> --- On Tue, 9/29/09, Reinier Zwitserloot <reinier at zwitserloot.com>  
> wrote:
>
> From: Reinier Zwitserloot <reinier at zwitserloot.com>
> Subject: Re: list literal gotcha and suggestion
> To: "Mark Thornton" <mthornton at optrak.co.uk>
> Cc: coin-dev at openjdk.java.net
> Date: Tuesday, September 29, 2009, 7:52 AM
>
> new HashSet<>(["a", "b", "c"]);
>
> is too much effort in the rare cases where you need to initialize a
> set-typed parameter? This is java, not perl. Golfing isn't the end  
> goal.
>
>   --Reinier Zwitserloot
>
>
> On 2009/29/09, at 09:42, Mark Thornton wrote:
>
>> Reinier Zwitserloot wrote:
>>> So, let's turn this argument on its head: Why are we trying so hard
>>> to  make set literals work? Why don't we just remove them from the
>>> proposal? The need for them seems minor compared to lists. When
>>> the  collection size is small (below about a 100), O(1) lookup
>>> performance  is irrelevant (and even if it was relevant, due to the
>>> extra
>> So that we can supply them as arguments to methods that take a Set
>> and onot a List or Collection, or to initialise Set typed fields.
>>
>> Mark Thornton
>>
>
>
>
>
>
>
>