Seems reasonable. Mike, can you ask Roland to join us on this thread?
Maybe he has some reason why this won’t work.
Thanks,
-Alex
On 6/1/15, 1:38 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>Just in case what I proposed in my previous email isn't quite clear, I
>wrote a little code to clarify. Here's a AS3 type definition for
>createjs.EventDispatcher that I created by hand:
>
>package createjs
>{
> public class EventDispatcher
> {
> native public function EventDispatcher();
>
> // static methods
> native public static function initialize(target:Object):void;
>
> // methods
> native public function addEventListener(type:String,
>listener:Object, useCapture:Boolean = null):Object;
> native public function dispatchEvent(eventObj:Object,
>target:Object
>= null):Boolean;
> native public function hasEventListener(type:String):Boolean;
> native public function off(type:String, listener:Object,
>useCapture:Boolean = false):void;
> native public function on(type:String, listener:Object,
>scope:Object = null, once:Boolean = false, data:Object = null,
>useCapture:Boolean = null):Object;
> native public function removeAllEventListeners(type:String =
>null):void;
> native public function removeEventListener(type:String, Object,
>useCapture:Boolean = null):void;
> native public function willTrigger(type:String):Boolean;
> }
>}
>
>It's based on this TypeScript definition:
>
>export class EventDispatcher {
> constructor();
>
> // methods
> addEventListener(type: string, listener: (eventObj: Object) =>
>boolean,
>useCapture?: boolean): Function;
> addEventListener(type: string, listener: (eventObj: Object) => void,
>useCapture?: boolean): Function;
> addEventListener(type: string, listener: { handleEvent: (eventObj:
>Object) => boolean; }, useCapture?: boolean): Object;
> addEventListener(type: string, listener: { handleEvent: (eventObj:
>Object) => void; }, useCapture?: boolean): Object;
> dispatchEvent(eventObj: Object, target?: Object): boolean;
> dispatchEvent(eventObj: string, target?: Object): boolean;
> dispatchEvent(eventObj: Event, target?: Object): boolean;
> hasEventListener(type: string): boolean;
> static initialize(target: Object): void;
> off(type: string, listener: (eventObj: Object) => boolean,
>useCapture?:
>boolean): void;
> off(type: string, listener: (eventObj: Object) => void, useCapture?:
>boolean): void;
> off(type: string, listener: { handleEvent: (eventObj: Object) =>
>boolean; }, useCapture?: boolean): void;
> off(type: string, listener: { handleEvent: (eventObj: Object) => void;
>}, useCapture?: boolean): void;
> off(type: string, listener: Function, useCapture?: boolean): void; //
>It is necessary for "arguments.callee"
> on(type: string, listener: (eventObj: Object) => boolean, scope?:
>Object, once?: boolean, data?: any, useCapture?: boolean): Function;
> on(type: string, listener: (eventObj: Object) => void, scope?: Object,
>once?: boolean, data?: any, useCapture?: boolean): Function;
> on(type: string, listener: { handleEvent: (eventObj: Object) =>
>boolean; }, scope?: Object, once?: boolean, data?: any, useCapture?:
>boolean): Object;
> on(type: string, listener: { handleEvent: (eventObj: Object) => void;
>}, scope?: Object, once?: boolean, data?: any, useCapture?: boolean):
>Object;
> removeAllEventListeners(type?: string): void;
> removeEventListener(type: string, listener: (eventObj: Object) =>
>boolean, useCapture?: boolean): void;
> removeEventListener(type: string, listener: (eventObj: Object) =>
>void,
>useCapture?: boolean): void;
> removeEventListener(type: string, listener: { handleEvent: (eventObj:
>Object) => boolean; }, useCapture?: boolean): void;
> removeEventListener(type: string, listener: { handleEvent: (eventObj:
>Object) => void; }, useCapture?: boolean): void;
> removeEventListener(type: string, listener: Function, useCapture?:
>boolean): void; // It is necessary for "arguments.callee"
> toString(): string;
> willTrigger(type: string): boolean;
>}
>
>The AS3 version gives me proper code hinting in Flash Builder, which is
>pretty sweet.
>
>- Josh
>
>On Mon, Jun 1, 2015 at 1:10 PM, Josh Tynjala <joshtynj...@gmail.com>
>wrote:
>
>> 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."
>>> >
>>>
>>>
>>
