Is language support for collections is a coin feature ?

Per Bothner per at bothner.com
Sat Sep 25 21:15:22 PDT 2010


On 09/25/2010 08:51 PM, Reinier Zwitserloot wrote:
> User user = new User()
>      .firstName("Remi")
>      .lastName("Forax")
>      .addAddress().zipCode("30785").done()
>      .address(new Address().zipCode("30785"));
>
> Note the two styles for address - you can pick either, whichever you think
> is nicer (don't, obviously, add both methods to the API!)
>
> As near to the cleanliness as the JSON syntax as makes no difference, and
> perfectly doable in java today. It does mean User and Address can't be
> immutable and that's a bit of a shame.

For immutable ("value") types you can define the firstName method
as one that takes a User and returns new User that has the same values,
expect with a modified firstName.

> User user = new UserBuilder() {{
>      firstName = "Remi";
>      lastName = "Forax";
>      addresses.add(
>          new AddressBuilder() {{
>              zipCode = "30785";
>          }},
>          new AddressBuilder() {{
>              zipCode = "67899";
>          }});
> }}.build();
>
> Sure, there's opportunity for cleanup. But I don't think it should be high
> priority. Especially because, even with the superfluous need for the double
> braces, the call to build(), and the need for an add method for 0-*
> 'fields': This beats the JSON example, because of all the safety measures.

Creating the extra UserBuilder adds some overhead, but it can perhaps
be optimized away.

I think there should standard compact way to do this.  Unless whether
it is best to use conventions or a syntax change.  Various issues tie
in with it:  properties; value types; block expressions.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/



More information about the coin-dev mailing list