I understand that, even with the best compiler technology, eliminating primitives still has a noticeable performance cost for some types of computation.

[E0, E1] T2[E0, E1] swap(E0 e0, E1 e1) { return t(e1, e0); }

If you had native tuples the above might look like

[E0, E1] (E0, E1) swap(E0 e0, E1 e1) { return (e1, e0); }

As you can see; not very different. The main difference would be access to the tuple members via .e0 etc., e.g.:

T2[Integer, Integer] maxMin = t( 0, 1 );
maxMin = swap(maxMin.e0, minMax.e1);

As opposed to:

(Integer max, Integer min) = ( 0, 1 );
(max, min) = swap(min, max);

On the other hand you can do:

class MyClass extends T2[Integer, Integer] { … }

with the library; most languages that have tuples don’t allow you to extend the tuple class.

1. Add a source keyword so that you can mark a file as Java 7, then you don’t need to worry so much about backward compatibility and you can fix up the errors from the past (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519124)

2. You can write a good tuple library already using generics:

T2 swap(E0 e0, E1 e1) { return t(e1, e0); }

Note generics and ease of construction.

You can see the code and more examples at:

http://code.google.com/p/google-collections/issues/detail?id=43

I would add properties and events (delegates), fix the lousy component model, make sure versioning is build in (i.e. non-virtual methods by default etc.) and drop pluggable L&F (people on a mac want the mac stuff and so forth). Operator overloading is long needed to fix a bunch of horrific API’s, nullable types would be nice, but for god sake get rid of the primitive types and add inference (would also fix the tuple issue). Oh god I want to go to that island so bad!

No structural typing is static and type safe. Duck typing is currently associated with dynamic typing. I guess some people would call “structural typing” chicken typing. But only because they have never been biten by a nasty type bug which had costed them k’s of USD.

“However, I don’t see having to declare “implements MyInterface” as being a problem in Java.”

a.) It creates a _broad_ dependency. Often too broad.
b.) What if you do not control the code to declare the dependency?

Peace
-stephan

I think that’s a pretty fundamental change to the type system and would require a new way of thinking when developing. It would however make my point about Cloneable irrelevant – we wouldn’t need a Cloneable interface, so I can see the attraction for simple interfaces.

However, I don’t see having to declare “implements MyInterface” as being a problem in Java.

The argument I’ve seen made against duck typing is the (extremely contrived) example of the ZipFile and the AtomicBomb types that both have an explode() method. Use the wrong object and you’ll get a rather different result that the one you expect.

I’m definitely with you on point 3 (ClassCastExceptions). There are no backwards-compatibility excuses for not doing this right now.

public void myFoo(T[public void doFoo()] foo)

to express that myFoo works with any type that has a doFoo method.

interface Foo {
public void doFoo();
}

Currently Java (contrary to Scala) only has declarative typing. So I only can call

public void myFoo(Foo foo)

with an object that DECLARES to implement foo. Java should look at my object if it does “implement” Foo by structural comparison, not because someone declared it to implement Foo. The Scala way of saying

public void myFoo(T foo)

is more powerfull, but less readable. I would prefer the interface way.

Peace
-stephan