tracker issue : CF-4187705

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

The parser / compiler falsely identifies methods as operators.

| View in Tracker

Status/Resolution/Reason: Needs Review//

Reporter/Name(from Bugbase): John Whish / John Whish (John Whish)

Created: 09/08/2016

Components: Core Runtime

Versions: 2016

Failure Type: Non Functioning

Found In Build/Fixed In Build: CF2016_Update1 /

Priority/Frequency: Major / Some users will encounter

Locale/System: ALL / Mac OS 9.04

Vote Count: 4

Problem Description:

The parser / compiler falsely indentifies methods as operators.

Steps to Reproduce:

{code:java}
<cfscript>
function filter() {
    return {
        "gte": function (n) {
            return n;
        }
    };
}


// compiler errors on this line...
// filter().gte(1);
</cfscript>
{code}


In the above example the `filter().gte(1);` errors on compilation. This is a problem as some java libraries expose methods that have the same method names as the CF operators - for example ElasticSearch uses `gt` `gte` `lt` and `lte` methods for the range filter.


Actual Result:

Errors on compilation

Expected Result:

The parser should be able to disguish when it is a method being called (operator immediatley preceded by a '.')

Any Workarounds:

Not in the case of interacting with Java objects. If just in CFML then rename the methods.

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

Watson Bug ID:	4187705

External Customer Info:
External Company:  
External Customer Name: John Whish
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

this shouldn't;t break - has caused issues with calling java objects with methods that happen to be the same as CF operators
Vote by Doug C.
1862 | December 16, 2016 03:42:31 PM GMT
Another example if it's useful that should be valid: <cfscript> function eq(a, b) { return a == b; } writeDump(eq(1, 2)); writeDump(1 eq 2); </cfscript>
Comment by John W.
1860 | December 16, 2016 03:42:58 PM GMT
Related ticket https://tracker.adobe.com/#/view/CF-4199987
Comment by John W.
1861 | October 11, 2017 07:17:40 PM GMT
Related ticket: https://tracker.adobe.com/#/view/CF-4201768
Comment by John W.
26414 | March 29, 2018 10:43:47 AM GMT
2 and a half years later and no comment from Adobe? :(
Comment by John W.
30165 | January 31, 2019 08:05:15 PM GMT
Hi all, I've verified this is fixed in CF2018 Final (build 2018.0.0.310739 ). Adobe, could this ticket please be added to CF2018's Issues Fixed list: https://helpx.adobe.com/coldfusion/release-note/coldfusion-2018-release-notes.html#bugfix I've also verified this issue is not yet fixed in CF2016 Update 7 (build 2016.0.07.311392). Can this be fixed in CF2016? It was certainly filed in time (filed w/in months of CF2016's release). Thanks!, -Aaron
Comment by Aaron N.
30170 | February 01, 2019 09:13:50 AM GMT
Thanks for checking Aaron :) Had a poke about and it's partially fixed. Example: https://trycf.com/gist/f4cfa96e66d24c9956bdd5c6c72e2321/acf2018?theme=monokai Any public method name in a java object should be callable from ACF regardless of if that method name happens to be an ACF operator
Comment by John W.
30171 | February 01, 2019 09:29:27 AM GMT
+1 - Needs fixed.
Vote by Aaron N.
30181 | February 02, 2019 05:06:44 AM GMT
Hi John, You're welcome! Aha, I retract the 1st part of my last statement then. Nice find there. I completely agree with what you said. This issue is -not- fixed and should not be added to CF2018's Issues Fixed list. +1, voted. Thanks!, -Aaron
Comment by Aaron N.
30180 | February 02, 2019 05:10:51 AM GMT