Anyone ever considered named tuples? (original) (raw)

Paulo Levi i30817 at gmail.com
Mon Mar 23 15:28:55 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"

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)

More information about the coin-dev mailing list