Anyone ever considered named tuples?

[Reinier Zwitserloot]

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.
>>
>>
>