On 1/8/16, 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.
For sure, there are scenarios it won't handle, which is why I'm looking at
directives that allow you to override what the compiler will do. I'm
trying to get a sense for how often folks code this way. For me it is
rare to catch type errors in outer function thrown from an inner.
Although I definitely do that for file read/write errors.
>
>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.
IMO, speed optimizations can also come via code hinting instead of
massaging, which is what these directives intend to do.
>
>
>> 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.
True, depending on the practical definition of "require". If the default
result is going to have performance problems then you have essentially
forced everyone to massage their code and then we lose the
lower-cost-of-migration advantage that I think we want to keep.
>
>
>> 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.
>
Of course it is doable. But we have to be concerned about its impact on
the greater eco-system of IDEs.
>
>
>> 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.
I will spend some time putting more options and directives around this
optimization so you can easily get what you want and what I think I want.
Thanks for your input,
-Alex
