On 1/8/16, 11:38 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:

>I wonder if we could define some kind of special global function that
>would
>make the compiler and IDEs happy with assignments that would normally
>require casting, but the JS emitter could strip out the function call and
>assign directly. We could take advantage of the fact that the * type can
>be
>assigned to anything without a cast:
>
>// Example "Implementation"
>
>function __assign(value:*):*
>{
>    return value;
>}
>
>// ActionScript Usage
>
>var before:SuperClass = new SubClass();
>var after:SubClass = __assign(before);
>
>// JS Output:
>
>var before = new SubClass();
>var after = before;
>
>As you can see, it becomes a simple assignment in JS, without the function
>call overhead.
>
>Obviously, if someone can come up with a better name than __assign(),
>that's cool. Just something off the top of my head.

Interesting idea.  It also requires massaging code which I am trying to
avoid.  I'm not opposed to anyone implementing it.  We can give folks
choices.

>
>It's worth noting that TypeScript casting does not have a runtime fail
>state. It's just there to make the compiler happy too. If the types in a
>cast aren't compatible at runtime, the code just continues running without
>error until the incompatibility surfaces elsewhere. This would have a
>similar effect.

One thing I should mention:  In my vision for FlexJS, folks would produce
a SWF version as well as a HTML/JS/CSS version. That isn't true for folks
doing native JS with JS.swc, but one of the advantages of having a SWF
version is that if even if you just use it for testing and never deploy
it, you will get the advantage of the Flash/AIR runtime verifier to help
you make sure all of your types and interfaces are matching up as they
should, making the need for checking in the JS version even lower.

For those of you who work on really large projects with cross-team
integration, this can be very important, because Flash will detect that a
module you loaded doesn't match the loader's interface expectations at the
time of the load, as opposed to waiting for you to finally hit the code
path that will expose the error.

-Alex

Reply via email to