tracker issue : CF-3737577

select a category, or use search below
(searches all categories and all time range)
Title:

Scope-handling with increment operator is glitch

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 04/06/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 1

Listed in the version 2016.0.0.297996 Issues Fixed doc
Verification notes: verified_fixed on August 25, 2019 using build 2016.0.01.298513
G'day:
Consider this code:
{code}
URL.somevariable = 0;
somevariable++;
writeDump(var={URL=URL,variables=variables});
{code}

The output is this:
<pre>
struct

URL:  
	[struct]
	SOMEVARIABLE: 0
VARIABLES:  
	[struct]
	SOMEVARIABLE: 1
</pre>

The result should be one of:
* URL.someVariable == 1
* an exception because variables.someVariable doesn't exist

Given CF's propensity for looking in scopes it shouldn't be (yes, by design, I know), the expected result should be that URL.someVariable==1, and variables.someVariable not being defiend at all.

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3737577

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

Actually I thought about this some more (ref: http://cfmlblog.adamcameron.me/2014/04/predictable-but-perhaps-unexpected.html), and not *sure* it's not expectable behaviour. Probably worth some consideration before erring one way or the other, though. -- Adam
Comment by External U.
12832 | April 06, 2014 06:32:54 AM GMT
Micha - the lead engineer @ Railo - had this to say: {quote} Getting and setting a unscoped variable is not following the same rules, normally a set of a unscoped variable is done on the variables scope... CFML (Railo included) is definitely wrong here, then this i++; // increment "i" // is not the same as i=i+1; // get "i", do a plus operation together with 1 and then assign the result to "i" incrementing a value means not to create a new value in a other scope! In Railo this was happening by accident, simply because it was the easiest way for the compiler to rewrite i++; to i=i+1;, so we not have to handle a lot of new operators (++i,i++,--i,i--,i+=1;,i-=1;,i&="",...). We changed that behavior in 4.2 for the next patch release, now railo writes bytecode specialized to deal with this unary operators, what is also faster by the way, because railo no longer has to look for the unscoped variable twice! I'm a 99% sure this happens by accident in ACF as well, in other words nobody ever planned that behavior at all. {quote} (ref: http://cfmlblog.adamcameron.me/2014/04/predictable-but-perhaps-unexpected.html#comment-1323524258) So they consider it a bug, and have fixed it. I can see where he's coming from. -- Adam
Comment by External U.
12833 | April 08, 2014 08:30:50 AM GMT
+1 ......................
Vote by External U.
12834 | September 28, 2015 09:43:54 PM GMT
Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Now, URL.someVariable is 1 and the variables scope remains empty. Thanks!, -Aaron
Comment by Aaron N.
31205 | August 25, 2019 08:10:56 AM GMT