ExtendScript Throws on Nested Ternary Operator

[romanroadsmedia]

Just filed this bug with Adobe, but wondering if anyone else has run into this:

ExtendScript wasn't listed in the products list for submitting a bug, so that's why I'm using the After Effects bug form for this issue.

When attempting to use a nested ternary (AKA conditional) operatory in ExtendScript (`<test1 expression> ? <test2 expression> ? <if test2 true> : <if test2 false> : <if test1 false>`), it errors rather than running as it should.

Steps to Reproduce Bug:

1. Open ExtendScript

2. Paste the following into a new source file (don't include the backticks): `true ? true ? "one" : "two" : "three";`

3. Run the script

Results: Errors at second question mark ("?") with the error: "Expected: : "

Expected Results: Should have run successfully and returned "one".

I assume that this is an artifact of the implementation of ECMAScript-262 for ExtendScript, but I don't know. This shouldn't error though.

Originally posted this question here and was directed elsewhere.

[Mathias Moehl]

Yes, there seems to be some differences in operator precedence in ExtendScript vs. modern JavaScript versions, which is a bit scary since it can create nasty bugs. Like this is works:

true ? (true ? "one" : "two" 😞 "three"

Another example is this one:

true || false && false // will evaluate to false in ExtendScript vs true in JavaScript
(true || false) && false // this is how ExtendScript interprets the statement
true || (false && false) // this is how JavaScript interprets it

This becomes nasty in particular if you run your code trough a minifier like UglifyJS which will remove the parenthesis and hence the minified and original code behave differently.

As far as I know, ExtendScript has not been improved by Adobe for years, so it is unlikely that they are going to do something about it, given that so little people noticed/complained about it.

[romanroadsmedia]

As far as I know, ExtendScript has not been improved by Adobe for years, so it is unlikely that they are going to do something about it, given that so little people noticed/complained about it.

That's what I was afraid of, so it's helpful to have that corroborated.

This becomes nasty in particular if you run your code trough a minifier like UglifyJS which will remove the parenthesis and hence the minified and original code behave differently.

Indeed -- the code above was a minimal example of output from the Google Closure compiler. Since the GCP outputs code compatible with ES3, I expected the output to work seamlessly with the ES3 in ExtendScript...

I now wonder if Adobe has long-term plans to keep ExtendScript alive. If it's been years since it's been updated, that's the definition of bit rot.

[Arie Stavchansky]

It's likely that Adobe will continue to suggest that developers implement extensions to their Creative Cloud apps using the CEP framework as it supports modern versions of ECMA.  However, ExtendScript will likely not be truly abandoned because of the breadth of host applications that use it and depend on it.  It seems more prevalent in the world of print than in video, and so it will be some time until CEP fully takes over.  Hopefully it won't go to the way-side like ActionScript did in Flash because it's not a technology that is squarely focused on the web.  I agree that ExtendScript feels like code rot, and it would be great if Adobe would support modern implementations of ECMA standards within ExtendScript.  Although, now that Stranger Things and the 1980s nostalgia are all the rage, at least it feels hip to code with ExtendScript 

[Mathias Moehl]

@Arie: also CEP panels use ExtendScript to interact with the host app. In that sense, they are not an alternative to ExtendScript but rely on it.