flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Dufilie <andy.dufi...@gmail.com>
Subject Re: [FALCONJX][FLEXJS] "as" keyword handling
Date Fri, 08 Jan 2016 19:03:12 GMT
On Fri, Jan 8, 2016 at 12:53 PM, Alex Harui <aharui@adobe.com> wrote:

> On 1/8/16, 7:23 AM, "Andy Dufilie" <andy.dufilie@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.

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