flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Tynjala <joshtynj...@gmail.com>
Subject Re: [FalconJX] d.as definition file (was: [FalconJX JXEmitter] Hello Greeter! working ... )
Date Mon, 01 Jun 2015 20:10:32 GMT
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 =

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:

Here's example where this might apply to converting TypeScript definitions
to AS3 definitions. JQuery has a static extend() function with these

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.lists@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.lists@gmail.com> wrote:
> > How is that different than adding “=null” to the signature?
> >
> > On Jun 1, 2015, at 4:56 PM, Michael Schmalle <teotigraphixllc@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."
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message