Yeah, I think optional parameters can default to null pretty safely. I have some other ideas to make the conversion easier.
I think we can use some simplified rules for overloads, at least to start out. If we want to do it like Randori, and create function signatures that map to a different name, that would be cool, but I don't think it's strictly necessary. 1) If the parameter names are the same, but the types are different, you can just type it as Object in AS3. People already do this in pure AS3 when multiple types are accepted. Here are the overloads from TypeScript's dispatchEvent() in the createjs.EventDispatcher class: dispatchEvent(eventObj: Object, target?: Object): boolean; dispatchEvent(eventObj: string, target?: Object): boolean; dispatchEvent(eventObj: Event, target?: Object): boolean; In AS3, these could map to a function like this: native public function dispatchEvent(eventObj:Object, target:Object = null):Boolean; 2) If the parameter names vary too much, then using ...rest should be an acceptable fallback. There is precedence in AS3 with this one too. The sort() function in the Array class has a signature with ...rest because the arguments are very flexible: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Array.html#sort%28%29 Here's example where this might apply to converting TypeScript definitions to AS3 definitions. JQuery has a static extend() function with these overloads: extend(target: any, object1?: any, ...objectN: any[]): any; extend(deep: boolean, target: any, object1?: any, ...objectN: any[]): any; AS3 doesn't really have a mechanism to handle an extra argument at the beginning, so it should fall back to ...rest, like this: native public static function extend(...rest:Array):Object; Not ideal, but I think it's a good start that can be easily expanded in the future with something like what Randori offered. - Josh On Mon, Jun 1, 2015 at 7:29 AM, Harbs <harbs.li...@gmail.com> wrote: > Okay. The obvious difference is that subclasses might not implement the > variable, but adding "foo=null” to the signature doesn’t sound like an > insurmountable task… > > On Jun 1, 2015, at 5:10 PM, Harbs <harbs.li...@gmail.com> wrote: > > > How is that different than adding “=null” to the signature? > > > > On Jun 1, 2015, at 4:56 PM, Michael Schmalle <teotigraphix...@gmail.com> > wrote: > > > >> "The main problems were method overloading and optional members. An > >> interface in TS doesn't necesarilly HAVE to be implement completely > >> by a class, by adding a question mark to the declaration you make that > >> member optional." > > > >
