Wednesday, 22 July 2015

ColdFusion CFML: weird shorthand operator restriction

I dunno what to make of this one. This morning I was taking a look at an issue in the ColdFusion docs that someone on the #cfml Slack channel had raised, in that the docs said this;

Arithmetic operators

+= -= *= /= %=Compound assignment operators. The variable on the right is used as both an element in the expression and the result variable. Thus, the expression a += b is equivalent to a = a + b.
An expression can have only one compound assignment operator.

The thing that I had my attention drawn to is Adobe's inability to know left from right, so I've fixed that in the wiki version of the docs. I can't fix the ColdFusion 9 docs, but equally don't care about ColdFusion 9 anyhow.

However there's another interesting statement there:
An expression can have only one compound assignment operator.

What? Why?

I duly knocked together an example and ran it on ColdFusion  11:

// multiple.cfm

a = 17;
b = 19;
c = 23;

a += (b += c);


And, lo, we get this:

I tried it on Lucee:

That's more like what I expected.

Still: I never know whether a glitch I see between CF and Lucee is the fault of one or the other these days, and perhaps there's some precedent in other languages wherein this might be illegal.

I knocked together versions of this code in PHP, JavaScript, Java, Python and Ruby, and the only other language that bleated was Python:


a = 17
b = 19
c = 23

a += (b += c)

print a
print b
print c

  File "", line 7
    a += (b += c)
SyntaxError: invalid syntax


Python has a reputation of being uppity about stuff, so I'll just ignore that and go with the precedent set by less retentive languages. ColdFusion is being daft here.

Not least of all because of this:

// multipleNoParentheses.cfm

a = 17;
b = 19;
c = 23;

a += b += c;


This works:

But here is my dilemma. Given the docs say there should be only one shorthand operator per expression... which of these ColdFusion examples is "wrong"? Is this limitation by design, in which case the no-parentheses version is "wrong"? Or is it a daft rule they decided to lift at some point, but didn't do a thorough job of it?

I guess it doesn't stand being analysed too much. The rule is a dumb one, and should not be there. I'll raise an bug report to get it removed: 4023966.