That's odd. I swear I remember someone from Adobe once explaining that function-style casting is faster than as-style casting (with the exception of primitive types that have a top level function that makes function-style casting impossible, as you mentioned in 1). I've tried to avoid as-style casting for years, based on this knowledge.
- Josh On Jan 7, 2016 7:24 PM, "Andy Dufilie" <andy.dufi...@gmail.com> wrote: > On Thu, Jan 7, 2016 at 8:27 PM, Alex Harui <aha...@adobe.com> wrote: > > > If "SomeType(somevar)" is not in a try/catch it will throw an exception. > > How often are you relying on that vs just trying to make the compiler > > happy? > > > > "function" casting is slower than "as" in ActionScript, so I have stayed > away from it. When I do use it, there are two cases: > > 1. If coercing to a primitive type, it actually tries to convert the value > to that type. With String(value) I expect it to give me a String via > toString(). With Number(value) I expect it to converting Strings to > Numbers and undefined -> NaN. I expect it to throw an error if the value > cannot be converted to a Number. Really I would rather have it return NaN > instead of throwing an error, but we can't change that behavior because > that's part of ECMAScript. > > 2. When coercing to a non-primitive, I mostly use it to get compiler > checking for the member variables or functions I access, but I would still > want it to throw an error even in JavaScript if it is not of the correct > type, because that's what it does in ActionScript and I expect the > cross-compiler to faithfully preserve the behavior. > > > On Thu, Jan 7, 2016 at 8:32 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > On 1/7/16, 5:24 PM, "Andy Dufilie" <andy.dufi...@gmail.com> wrote: > > >if (obj is Thing1) > > > (obj as Thing1).foo(a,b); > > >else if (obj is Thing2) > > > (obj as Thing2).bar(x,y); > > > > There are no plans to change "is", just "as". Are you using "as" as a > > test or just "is". In the example above, you are using "as" just to make > > the compiler happy. > > > > > It's used above to get compiler checking in case I misspelled foo() or > bar(), or if I pass in bad variable types to either function. In the next > example, I'm relying on "as" to change the value to null without throwing > an exception if it is not of the correct type. The code will break if that > behavior is not preserved: > > var thing1:Thing1 = obj as Thing1; > var thing2:Thing2 = obj as Thing2; > if (thing1) > thing1.foo(a,b); > if (thing2) > thing2.bar(x,y); > > Here is similar real-world code relying on this behavior and it will break > if "as" is removed by the cross-compiler: > > > https://github.com/WeaveTeam/Weave/blob/13f98136a8cfd8dc4662f6014abcd5aa87baa56d/WeaveJS/src/weavejs/core/SessionManager.as#L335 > > > > > >I see "is" and "as" as highly useful features, and I think it would be a > > >mistake to make the code cross-compile into something that behaves > > >differently by default. IMO if cross-compiled code behaves differently > > >than the original then it's being mangled and can't be trusted. > > > > That's the root of my question: how many folks us "as" to actually > convert > > data vs just make the compiler happy. Again, no plans to change "is". > > > > > This is not just about making the compiler "happy." It's about getting the > benefit of compiler checking to alert you when you've typed the wrong > member variable / function name, or giving the wrong parameter types. If I > was only concerned about making the compiler happy (preventing it from > yelling at me), I could just use Object(value).whatever() or use untyped > variables everywhere. I may as well use plain JavaScript at that point. > > We shouldn't be planning to change anything that would cause the > cross-compiled to code to behave differently than the original source. > This is not something that should require a vote - it is an error to change > the behavior of code during cross-compilation. If such an option is added > to omit portions of code by default, then the compiler should give you a > warning for every place that occurs so the user knows exactly what is > happening. Otherwise the cross-compiler cannot be trusted. > > > > > > > > >A related issue is when setting a typed variable or passing in a > parameter > > >to a function, it will do type coercion automatically in AS but that > > >behavior is lost when cross-compiling to JS. For example, I have > > >situations like this where I now have to add manual type casting, and I > > >wish the compiler would do that automatically: > > > > > >var str:String = value_which_may_be_a_number; > > > > What error are you getting? I thought the auto-conversion worked for > both > > JS and AS. > > > > -Alex > > > > > Auto-conversion is currently not done for function parameters or variable > assignment. > > AS input: > public function testfunc(a:String, b:String):Array { > var c:String = a; > var d:String = b; > return [typeof a, typeof b, typeof c, typeof d]; > } > > JS output: > testfunc = function(a, b) { > var /** @type {string} */ c = a; > var /** @type {string} */ d = b; > return [typeof(a), typeof(b), typeof(c), typeof(d)]; > }; > > This code: > var foo = testfunc; > return foo(1,2) > will return ['string', 'string', 'string', 'string'] in ActionScript, but > ['number', 'number', 'number', 'number'] in JavaScript. >
