hg: valhalla/valhalla/langtools: Add some functional juice to javac code
david.r.chase at oracle.com
Tue Aug 12 20:40:55 UTC 2014
I’d be interested in knowing the ultimate intention for tuples; if it is value types,
this subtyping is less useful because I think we intend restricted subtyping among
value types. If we use them to model a parameter list (maybe not for Java) tuple
subtyping can indeed mask errors — if we have overloading among
foo [ animal ]
foo [ fish, fish ]
and call “foo [ trout, eagle ]” instead of a type error, we invoke the first one.
Similar surprises are possible in a pattern matching world.
On 2014-08-12, at 2:10 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> Regarding subtyping vs. flat - main motivation here:
>> By Liskov, a 3-element tuple is also a 2-element tuple - i.e. it has a first and second element. It's a different way of thinking about tuples - if you think about them as record types, what I ended up with is closer with what the theory says. Maybe we don't care this degree of fidelity - but again, this is an internal implementation.
> Liskov is about types and behaviors, there is no field in Liskov world.
> I think that if Tuple3 is a subtype of Tuple2, it will hide some bugs instead of allowing polymorphic code.
> Mapping a Tuple3 to a Tuple2 by explicitly discarding one arguments is IMO better.
> stream.map(tuple3 -> new Tuple2<>(tuple3.item0, tuple3.item1)). ...
> and again, tuples are value types for me; if you want subtyping, you should not use class inheritance
> but tuple implementation should implement a hierarchy of interfaces.
More information about the valhalla-dev