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.
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.
- Josh
On Fri, Jan 8, 2016 at 11:03 AM, Andy Dufilie <andy.dufi...@gmail.com>
wrote:
> On Fri, Jan 8, 2016 at 12:53 PM, Alex Harui <aha...@adobe.com> wrote:
>
> >
> > On 1/8/16, 7:23 AM, "Andy Dufilie" <andy.dufi...@gmail.com> wrote:
> >
> > >In all above cases, if Foo is a primitive type, function-style casting
> can
> > >never be optimized out because Foo(x) will actually change the type of
> x.
> > >For example, String(x) will convert null to the String "null".
> >
> > Well, IMO, it isn't always NO. Sometimes you can optimize that code
> away.
> > It isn't "never". Currently, FalconJX does know if you are using
> > function-style casting to primitives and won't optimize that away.
>
>
> Does it know if this code is using primitive casting or not?
> var type:Class = String;
> var y = type(x);
>
> And what I'm playing with now for function-style casting won't optimize it
> > away if it finds a try/catch around it.
> >
>
> But that won't work if the try/catch is in function A that calls function B
> which has the function-style cast.
>
> You were just complaining about how much code massaging you have to do.
> >
>
> I'm happy with the current situation where it preserves the behavior of the
> explicit type casting code and I recommend not changing it. Speed
> optimizations will always require code massaging. If you're referring to
> automatic casts for typed variables and parameters, I can live with that
> because I know if the compiler added those casts everywhere that the
> performance hit would likely be too much, but I wouldn't be opposed to
> adding that automatic casting with an option to enable or disable it.
>
>
> > We've heard similar feedback from others, so my first instinct is to find
> > a way to give you control over your code output with less massaging.
> This
> > new syntax would still require massaging.
>
>
> Adding new syntax does not *require* massaging to existing code, because
> you don't *have* to update your code to use the new syntax. It should be
> looked at as an optional speed optimization for those that are
> performance-conscious. If you change the behavior of existing syntax, then
> that does require massaging.
>
>
> > The @flexjsignorecoercion (or
> > now @flexjsemitcoercion) is a function-level directive. We could add
> > project-level, file-level and/or line-level directives if that is easier
> > than massaging the code.
> >
>
> If you insist on making the compiler misbehave by default, then a
> project-level setting to bring it back to the correct behavior is
> absolutely necessary. I'd rather not have to add a directive to every
> single function just to prevent the compiler from mangling the code. If I
> write an explicit cast, I expect the compiler to respect that rather than
> act like it knows better.
>
>
> > IMO, an optimizing compiler would be smart enough to know when to remove
> > the Language.as calls. All I'm trying to provide is some smarts in the
> > compiler to do that optimization and some directives to help if we get it
> > wrong.
> >
>
> I believe risky automatic optimizations should enabled or disabled through
> a flag passed to the build command. The default behavior of the compiler
> should be to preserve the behavior of the code. Extra directives should not
> be required to let the compiler know that you actually mean what you typed
> if what you typed is valid code. Why should we have to tell it twice
> everywhere? ("Hey compiler, do this. No, seriously, I really want you to
> do what I just asked you to do.")
>
>
> > If you still want to add a new language feature, (x:Foo) is valid pattern
> > in a function parameter list, so I don't know if the compiler would give
> > you trouble implementing it. Another option might be another keyword
> like
> > "as" (maybe "_as_").
> >
>
> I'm feeling the pain of the performance hit, but I am opposed to breaking
> language features by default, so I would like to explore different options.
> I think (x:Foo) is doable.
>
>
>
> > I think I will put the circularity scan as a compiler option for folks
> who
> > still need it.
> >
>
> I think it's a good idea to disable the scan by default because the error
> messages actually help you write better code, which is the job of compilers
> and IDEs. It still needs to be an option to support existing codebases.
>
