Okay, since I've spent the whole damn day talking about other people's languages, let me tell you something that I would give a lot of thought to if I were designing a language. Consider C# 3.0 extension syntax:
static void Foo(this String s){ ... }
static void Foo(this Int32 i) { ... }
s = "hello";
i = 42;
s.Foo(); //resolves to Foo(this String s)
i.Foo(); //resolves to Foo(this Int32 i)
Now consider:
static List Sort(this List where this.Length \< 1000000) { ... }
static List Sort(this List where this.Length >= 1000000) { ... }
Or:
static Double SquareRoot(this Double i where i >- 0) { ... }
static Complex SquareRoot(this Double i where i \< 0) { ... }
Or:
static int Minimum(this TreeNode where treeNode.left.InstanceOf(EmptyNode){ return this.data; }
static int Minimum(this TreeNode) { return this.left.Minimum(); }
This idea of dispatching not just on the type of this, but on more complex (and dynamic) conditions, is called "predicate dispatch." Putting aside the specifics of syntax, I think that predicate dispatch is to object dispatch what unit testing is to explicit typing: a more general and more domain-specific alternative that provides more flexibility, although with potentially serious runtime implications. But maybe not as much as you'd think.
Note the similarity to COmega's chords:
public class Buffer {
public async Put(string s);
public string Get() & Put(string s) { return s; }
}
Calls to Buffer.Get() block until at least one call to Buffer.Put() has concluded, and then Get() actually has access to the s parameter of Put().
An abstraction that increases structural flexibility, allows domain-specific flexibility a la unit testing, and might address concurrency? Me likey.