I should add that I strongly agree with Andy that we shouldn't change the
default behavior of the existing forms of casting. That's why I made the
above proposal for a special function that the emitter would know to strip
away. It would allow us preserve the existing casting behavior, while
providing a separate option that simply makes the compiler and IDEs happy.
It's something additional to learn instead of discovering that what you
already learned is now completely wrong. I think that's safer and less
likely to make people angry and frustrated.
- Josh
On Fri, Jan 8, 2016 at 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.
>
> 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.
>>
>
>
