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

Reply via email to