incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffry Houser <jef...@dot-com-it.com>
Subject Re: Method overloading work-around: the problems & possible solution
Date Mon, 16 Jan 2012 17:49:55 GMT
On 1/16/2012 12:30 PM, David Arno wrote:
> Now imagine we have a modified version of the compiler that supports method
> overloading. AB compiles to:
> class AB ->
>    foo_String_void ->  String ->  void ->  {}
>    foo_int_void ->  int ->  void ->  {}
>    foo_uint_void ->  uint ->  void ->  {}
>    foo_Number_void ->  Number ->  void ->  {}
>    foo_Object_void ->  Object ->  void ->  {}

  I'm no compiler expert, so don't understand what your syntax 
communicates there.
  But, my intuition is to also add a foo method in there, like this:

  foo(argument:*):void{
    if (argument is String){
     foo_String_Void(argument);
   } else if (argument is Object ){
     foo_Object_void(argument);
   } else
     // etc...
  }

  The 'is' won't work with non object types (ints, uints?) will it?  
But, I'm sure the same concept above could be tweaked.

> There are problems with this. First the compile time problems:
>
> 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 we do what I envision about; the compiler wouldn't have to worry 
about it; the generated instance of ab would.

> I think the first problem (which method to use when the data is ambiguous)
> can be solved by a set of simple rules. I think the other problems could be
> solved if we modify what AB gets compiled to:
>
> class AB ->
>    foo_String_void ->  String ->  void ->  {}
>    foo_int_void ->  int ->  void ->  {}
>    foo_uint_void ->  uint ->  void ->  {}
>    foo_Number_void ->  Number ->  void ->  {}
>    foo_Object_void ->  Object ->  void ->  {}
>    foo ->  Object ->  void ->
>    {
>      if (p1 is String)
>      {
>        call foo_String_void, p1
>      }
>      ...
>    }
  Oh, yeah, you were a step ahead of me.

> We put in place a catch-all foo that handles all the situations where the
> compiler cannot work out the mapping at compile time.
>
> Thoughts?

  I was thinking something similar; so yeah.


-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Mime
View raw message