Anyone ever considered named tuples?

[Paulo Levi]

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


I don't think this is enough, simply because the main annoyance for these data
objects is the typesystem pollution with methodless(oo-less) objects.
If we had structural typing, yes, i'd shup up in a instant, and just
use the yet another
data container since i wouldn't have to extract the data before
passing it to a library,
but if we aren't going to get it (oh it would be soooo cool), i prefer
we got a minimal,
classless - typeless outside the parameters - way
to declare data objects that libraries could use. A swissland of data objects.

I know I'm being contradictory. For one I'd not like names at class level
(as a library creator to avoid having to create yet another data container
and as a library user to have to assimilate the data object) but on
another hand,
i'd like at least token self documenting semantic meaning as a library
user - given by the library code.
For instance:
List<(String parentDirectory, String file)>
getChildrenBindingToPosixMethod(File parent)