> About multimethods, it is said
> """
> We might have wanted to experiment with something more
> radical such as multi-methods, [...]. It would have been
> an exciting possibility to explore, but we didn't do it
> because we wanted to stay compatible with Java.
> """
>
> I don't understand: the Nice language had multimethods for
> many years and it was still compatible with java, so why
> where they considered incompatible with java when
> designing scala?

Well there's compatible and compatible. For instance Swing uses static overloading in really wild ways. Can we guarantee that a multi-method scheme would still always resolve correctly? Can we guarantee that one can write new Swing components that always work correctly? Maybe we can, but I just don't know for sure. I would have liked to have had the time to explore this in depth when Scala was first designed.

What scared me off at that time was that MultiJava had both multi-methods and a separate static overloading mechanism.
Given that this is rather clunky and MultiJava's designers are bright people, the only reason for them doing this that I could imagine was compatibility problems. But I might have been too paranoid.

Btw, are there signficant applications using Swing in Nice (inluding ones that define their own components)? If yes, that would be a good indicator that the problems are more mangeable than I feared.

I was not sure about pattern matching at first and I'm still not completely sure I understand how to use it to it's full potential but it's clear that it does everything you can do with multi-methods and more. It's more explicit than multi-methods too. If I had my druthers, I'd get rid of method overloading completely in Scala. It's been one of the biggest sources of hair-pulling for me in my Java career and doesn't provide any real benefits.

> but it's clear that it does everything
> you can do with multi-methods and more.

hmmm.