Re: JEP 186: Collection Literals

[Timo Kinnunen]

Hi, 


Re: “At least, in term of documentation, this kind of Builder is better, you 
can find it easily because it's a constructor of the Collection 
implementation you want to create.”


This is a quite delicate ‘pro’ that could also be considered a ‘con’. Being a documented part in the Collection instance means a change to the implementation of the Collection instance and that means a change for all users of the Collection implementation regardless of whether their source code makes or would make use of the new alternative construction syntax.


A static method callable with an additional alternative syntax could also retrofit existing Collection-like implementations without affecting their existing users as long as they don’t bring the static method into their scopes. If the alternative call syntax is enabled by using an annotation, then that annotation can also act as documentation for users and as a reference for IDEs.










-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Remi Forax
Sent: ‎Thursday‎, ‎January‎ ‎16‎, ‎2014 ‎15‎:‎11
To: Howard Lovatt
Cc: lambda-dev at openjdk.java.net





On 01/16/2014 02:39 AM, Howard Lovatt wrote:
> It would be interesting to compare which was best for the case of 
> object literals. Do you have an insight into the pro's and con's?

At least, in term of documentation, this kind of Builder is better, you 
can find it easily because it's a constructor of the Collection 
implementation you want to create.
In term of performance, it should be equivalent because the JIT 
routinely inline constructor and if the body of the lambda is too big to 
be inlined, you will get the same issue with a classical Builder.
I haven't checked if the VM is smart enough to consider that the profile 
inside the constructor is less important that the profile that comes 
from the code that call the constructor but I hope so
(I will double check when I will be a little less busy).

Rémi

>
>
> On 16 January 2014 10:43, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 01/16/2014 12:24 AM, Howard Lovatt wrote:
>     > I don't like limited solutions that are reserved for the
>     language and would
>     > therefore prefer an exploration of general solutions to the
>     problem. In
>     > this particular case, won't we be using Streams anyway :). Therefore
>     > solutions for Lists etc. are past their use by date :).
>     >
>     > I think there are two categories for a generic solution, (1) use
>     a static
>     > factory method or (2) use a builder class. The following example
>     (syntax
>     > arbitrary) illustrates the issues and relative strengths of the two
>     > approaches:
>     >
>     > IntStream is = {1, 2, 3};
>     >
>     > This could be translated using a static factory (1) into:
>     >
>     > IntStream is = IntStream.of(1, 2, 3);
>     >
>     > Or using a Builder class (2) into:
>     >
>     > IntStream is = IntStream.builder().add(1).add(2).add(3).build();
>
>     We can also use the Builder Pattern of Ruby now that we have a
>     lambda syntax
>        new ArrayList<>(builder -> builder.add(1).add(2).add(3));
>
>     Rémi
>
>
>
>
>
> -- 
>   -- Howard.