In the Randori compiler, I wrote the emitter to strip the cast during the
emit stage.
Mike
On Fri, Jan 8, 2016 at 2:38 PM, 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.
> >
>
