There are times when I consider it convenient to use "as" for casting and check for null, but it's not frequently. Usually, I use "is" instead. Most of the time, I use the other form of casting that results in a runtime error when the cast fails. I hope that runtime error won't be removed. Or at least could be turned on globally during debugging.
In regards to 2, is it not possible to walk the prototype chain of any JavaScript object? Or am I misunderstanding? - Josh On Thu, Jan 7, 2016 at 1:55 PM, Alex Harui <aha...@adobe.com> wrote: > How many of you use the "as" keyword as part of a test? IOW things like: > > var foo:SomeType = someVar as SomeType; > if (foo == null) > > IMO, I have yet to use "as" in this way in the FlexJS framework. I just > use it to make the compiler happy. IOW things like: > > var foo:SomeType = someVar as SomeType; > foo.someProp > > If foo really isn't of SomeType, I am going to get an NPE, but I know it > will never be null, I am just casting/coercing so the compiler will check > that someProp really exists on SomeType. > > The reason I'm asking is because the use of "as" as become a negative > factor in several cases: > 1) In JS, it results in a function call > 2) As Om noted yesterday, it doesn't work for Native JS types > 3) It causes unnecessary class dependencies which complicates the > goog.requires list > > Currently there is an @flexjsignorecoercion hack you can use to tell > FalconJX to skip code-generation for an "as" operation. However, we are > adding more and more of these, and they are more frequently the cause of > something not working, so I am thinking about flipping the logic and not > generating code for any "as" operation unless you specifically ask for it > via @flexjsgeneratecoercion or something like that. > > Thoughts? > -Alex > >
