On 1/16/12 9:30 AM, "David Arno" <da...@davidarno.org> wrote:
> class TestAB
> {
> public function testFoo():void
> {
> var ab:AB = new AB();
> ab.foo(1); // <- which foo does this call? int, uint or Number?
> ab.foo(null); // <- and this one? String or Object?
> ab["foo"](""); // <- how do we map this to ab.foo_String_void() ?
> }
> }
If you are going to change the language, you might as well make it stricter
and report an error and ask for foo(int(i)) or foo(null as String). I think
Java would report an error in this situation.
>
>
> I think the first problem (which method to use when the data is ambiguous)
> can be solved by a set of simple rules.
I would recommend some new global function called something like
getOverloadedMethodName("foo", ...) that takes the list of types or
parameters and computes the decorated name. If the compiler can do it, we
can do it at runtime. Also remember that in AS, a function call is a
shorthand for function.call() so I think there may always be use cases not
supported by the compiler.
> We put in place a catch-all foo that handles all the situations where the
> compiler cannot work out the mapping at compile time.
A catch-all will be slow and it is very easy to end up there since we don't
force strong-typing in the code. Probably better to simply to be stricter
and simply not allow ambiguity. You could also introduce a new keyword to
mark one method as the "default" or "catch-all"
>
> Thoughts?
>
> David.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
