I'd say lombok's approach is miles better here - at the end of the day supertypes are public. When you extend class X then everybody else knows it and it's part of your (public) API. I can write Pair<X, Pair<Y, Z>> foo = new Person(...) and that'll work. I can't tell from an API which supertypes are meaningful and which are accidental quirks of implementation that I shouldn't rely on.
Incidentally, a new feature we're about to roll out for lombok is that you subclass without subclassing: Create a field, stick a @Delegate annotation on it, and each method in that field's type (sans what's already in Object.java and methods you've already written yourself) is generated, with an implementation that just forwards the call to object referenced by the field. Unfortunately making this work without obscure caveats in eclipse is really, _really_ difficult. Whatever we end up writing for lombok is pretty much guaranteed to be a known painpoint, at least if you ask me or one of the other lombok developers, or we wouldn't be adding it. So, yeah, you're definitely picking at a java scab here. I simply doubt that the structural typing approach is a good way to solve it. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
