Eh, Roland is done with AS3/Flash, he uses TypeScript now. He also said to
tell you he is no longer affiliated with as3commons and you could contact
Christophe about your zip lib question.
I was lucky enough to get this info from him as he was trying to talk me
into doing TypeScript.
But it seems that you guys don't mind sacrificing type correctness on the
arguments in the AS definitions. It still looks like a task to resolve this
information when creating the as definitions.
Mike
On Mon, Jun 1, 2015 at 4:45 PM, Alex Harui <aha...@adobe.com> wrote:
> 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."
> >>> >
> >>>
> >>>
> >>
>
>
