Anyone ever considered named tuples?
Reinier Zwitserloot
reinier at zwitserloot.com
Sun Mar 22 06:55:56 PDT 2009
Actually, you could create this quite simply without changing the type
system by allowing a simpler syntax to create POJOs. Something like:
public data class Person {
String name;
int age;
boolean male;
}
which would be compiled to a method with those fields as private
final, 1 constructor (would dovetail nicely with the 'named'
suggestion), 3 public getters named according to javabean semantics
(getName, getAge, isMale), a toString, an equals, a hashCode, and a
clone method. You can add more methods to it if you want to, and even
replace the auto-generated ones (if its already there, it won't be
autogenerated).
--Reinier Zwitserloot
On Mar 22, 2009, at 01:41, Neal Gafter wrote:
> The standard name for this kind of thing is "structural types".
> Today, when
> this kind of need arises in Java people are forced to define a POD
> ("plain-old-data") class (nominal type) as the container. Without
> considering its merits, as an extension of the type system such
> things are
> out of scope for project Coin.
>
> On Sat, Mar 21, 2009 at 5:07 PM, Paulo Levi <i30817 at gmail.com> wrote:
>
>> Out of the blue, a few days ago, i wondered if a tuple construct
>> that had
>> names,
>> ie: (String directory, String file) for instance, would make any
>> sense?
>> I know that spaghetti code should be factored to map to simple
>> functions
>> with simple return arguments, but i saw sooooo much code that had
>> simple
>> container semantics.
>> A tuple object written as a compiler code transformation like
>> autoboxing
>> would make
>> a lot of sense if it allowed names to be defined at use site.
>> I'm sure you know that this can be simulated by some creative use of
>> generics and static import,
>> but the names (one ... first) are pretty bad.
>>
>> Just throwing a idea, don't bite my head off.
>>
>>
>
More information about the coin-dev
mailing list