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