Metamodel: deal with Java overloading

[FroMage]

The APIs are not currently made to support this, we need to figure it out.

[FroMage]

@gavinking any idea how I should implement that? I expect you don't want overloading to leak in the API?

I'm very tempted to move this out to 1.2

[gavinking]

I'm very tempted to move this out to 1.2

Fine by me.

[FroMage]

The thing about the metamodel is that people will expect that we can do type(foo) on anything even if foo is a Java instance. So naturally Java idioms tend to leak.

Given Java's overloading we can't even detect overloading without lots of work, for example:

class Top {
 public void foo(){}
}
class Bottom extends Top {
 public void foo(int i){}
}

There is overloading, and yet none of these methods will be marked as being overloaded or an abstraction. The questions are:

• Do we need to support overloading in any way (invoke one or both foo given a Bottom instance)
• If yes how, and when (I strongly suppose it can wait for post-1.0)
• If not yet, do we need to do anything about overloading ATM, like skip abstractions (abstractions do not have a valid return type, at least for methods) or how the metamodel should react given overloading?

[gavinking]

• Do we need to support overloading in any way (invoke one or both foo given a Bottom instance)

There are no instances of Nothing. So that's impossible,

• If yes how, and when (I strongly suppose it can wait for post-1.0)

It can wait.

• If not yet, do we need to do anything about overloading ATM, like skip abstractions (abstractions do not have a valid return type, at least for methods)

Sure, either:

1. skip 'em,
2. return a Method<Foo,Anything,Nothing>, or
3. throw an exception.

I guess option 2 is preferable.

[FroMage]

Sorry no time for 1.0

[FroMage]

Moving to 1.2