tracker issue : CF-4019629

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

Numeric literals should be Double, not String

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Sean Corfield / Sean Corfield (Sean Corfield)

Created: 07/10/2015

Components: Language, Java Integration

Versions: 2016,11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final / 2018.0.0.308164

Priority/Frequency: Trivial / Some users will encounter

Locale/System: English / Mac 10 All

Vote Count: 17

The fact that ColdFusion stores numeric literals as strings and converts them on demand makes Java interop harder than it needs to be because you have to insert casts all over the place. See for example this code:

https://github.com/framework-one/cfmljure/blob/master/index-acf.cfm

and compare to this code:

https://github.com/framework-one/cfmljure/blob/master/index.cfm

In addition to Java interop concerns, storing numeric literals as strings means extra conversions are needed, making numeric operations slower in ColdFusion (than Railo/Lucee, for example, which do store numeric literals as Double).

Proposal: change representation of numeric values to be Double by default and convert to String as needed instead of the other way around.

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

Watson Bug ID:	4019629

External Customer Info:
External Company:  
External Customer Name: Sean
External Customer Email:  
External Test Config: My Hardware and Environment details: Any. The code linked to above has been tested on ACF11 on both Mac and Windows and the casts cannot be removed.

Attachments:

Comments:

Good point. Try to make this more efficient please.
Vote by External U.
6704 | July 10, 2015 03:05:24 PM GMT
I agree one hundred percent. Is that 25? But seriously, I can only see upsides to doing it Sean's way.
Vote by External U.
6705 | July 10, 2015 03:18:58 PM GMT
yes please, yes please, yes please, yes please, yes please, yes please
Vote by External U.
6706 | July 10, 2015 03:36:58 PM GMT
+1 Please explain in 25 characters or more how this feature impacts productivity and why you are adding a vote.
Vote by External U.
6707 | July 10, 2015 04:51:13 PM GMT
+1 I only see the upside of doing this, and should be the way it worked to begin with
Vote by External U.
6708 | July 10, 2015 04:58:41 PM GMT
Because Sean says it should be.
Vote by External U.
6709 | July 10, 2015 05:32:38 PM GMT
Long overdue in a time where the key to complex projects is combining the most suitable tools to get the job done.
Vote by External U.
6710 | July 11, 2015 03:58:52 AM GMT
Numeric literals should be Double, not String
Vote by External U.
6711 | July 11, 2015 04:09:52 AM GMT
+1 .......................
Vote by External U.
6712 | July 11, 2015 12:21:12 PM GMT
+1 ===========================
Vote by External U.
6713 | July 11, 2015 07:54:47 PM GMT
+1 .......................
Vote by External U.
6714 | July 12, 2015 10:48:11 PM GMT
would make more sense and increase performance hopefully.
Vote by External U.
6715 | July 13, 2015 02:33:23 AM GMT
Would be a good enhancement.
Comment by HariKrishna K.
6689 | July 16, 2015 12:13:20 AM GMT
This has backward-compatibility implications. We'd made this change but saw several applications break because of the change, and had to eventually roll-back the fix.
Comment by Vamseekrishna N.
6690 | September 25, 2015 04:13:36 AM GMT
What happened to your promise that CF12 would break backward compatibility to fix the language? And how does this change break code? Railo/Lucee have always behaved this way: that's why they're faster than ColdFusion in so many cases and why Java interop is so much better on those engines.
Comment by External U.
6691 | September 26, 2015 01:03:01 AM GMT
I am also keen to hear how this broke backwards compat? CFML is a loosely/dynamically typed language, so if you can cast a string to a numeric when you need to, then you ought to be able to cast a numeric to a string (etc) when you need to. It's a fundamental of the language! You need to feedback more than just "backward-compatibility implications". What broke? Which applications? Was it a case of poor code in the application, or incomplete implementation on your part, or what?
Comment by External U.
6692 | September 26, 2015 04:36:14 AM GMT
Hi all, "The decision is not to break any backward compatibility for CF12." Please see Adobe's comment on CF-3148706. Thanks!, -Aaron
Comment by External U.
6693 | September 28, 2015 02:18:34 AM GMT
+1 ......................
Vote by External U.
6716 | September 28, 2015 02:20:20 AM GMT
Adobe, Can you please answer Sean and Adam in more detail? "several applications break" ? That's not very detailed. Thanks!, -Aaron
Comment by External U.
6694 | September 28, 2015 02:22:40 AM GMT
I have to agree that "several applications break" is very vague and since it was never released in the wild that can only mean internal applications. Since your customers are asking for it, I would ask that you reconsider and stick with the promises made two years ago that backward compatibility would be sacrificed for the future and functionality of the language.
Comment by External U.
6695 | September 28, 2015 07:12:29 AM GMT
Can you please provide more detail? Why do some apps get to hold back the future of ColdFusion? Are these apps more important then other apps?
Comment by External U.
6696 | September 30, 2015 03:28:53 PM GMT
+1 Hey - maybe consider removing the vote 25/4K rule that we've been asking for since it was required. Pretty please?
Vote by External U.
6717 | September 30, 2015 03:30:24 PM GMT
............................................ +1
Vote by External U.
6718 | September 30, 2015 04:31:12 PM GMT
............................................ +1
Vote by External U.
6719 | October 13, 2015 04:07:27 PM GMT
*bump* Adobe, you have unanswered questions below. Please don't continue to ignore. Thanks!, -Aaron
Comment by External U.
6697 | December 04, 2015 05:39:48 AM GMT
It broke many of our regression tests and many applications that we use to test and therefore it is certain that it would break most of the existing applications.
Comment by Rupesh K.
6698 | December 10, 2015 11:39:38 PM GMT
This smells to me like you didn't do a thorough job of the implementation. Given CF *can* handle values which are in fact doubles quite readily (see http://trycf.com/gist/9ddb31ad6d693ab0bbc3/acf11?theme=monokai => java.lang.Double), it's only the *literal* initialisation which uses strings all the time, then doesn't this point to your implementation of this being crocked some how? A change in the *starting value* of a variable should not break anything other than specifically testing for it to be a string, surely? As soon as one uses a variable that's a double as a string, CF will handle it (http://trycf.com/gist/7e660cff7d9b4102b77c/acf11?theme=monokai). Can you please provide *concrete* examples of where this change will break a regression test (ie: show us the test code), and "many applications". What code is it that's erroring? The one situation I can think of is this: http://trycf.com/gist/20831552cbe144fb3321/acf11?theme=monokai, where the user initialises a variable *as a numeric* then proceeds to use it as a string. How prevalent is this? I would think: not very. And it's perhaps worth breaking that code to make all the CFML code which needs to interop with other (type-sensitive) systems more robust. Blimey, you could even put a system setting in somewhere to "preserve old crappy behaviour" or something. I think your position needs further clarification, and the issue further discussion.
Comment by External U.
6699 | December 11, 2015 02:46:18 AM GMT
+1 for Adobe to show us actual code that breaks. Thanks!, -Aaron
Comment by External U.
6700 | December 11, 2015 05:00:46 AM GMT
It's also worth pointing out that Railo/Lucee store literal numerics as Double, not String, and yet people are able to port code back and forth between ColdFusion and those engines with no problems in this area. As Adam says, if your implementation broke that much code, maybe your implementation was wrong? I'll add my voice to those asking for concrete examples you say broke, so that we can test it on Lucee. If it breaks on Lucee, fair enough, but if works there, then your implementation was wrong and you need to try again to fix this.
Comment by External U.
6701 | December 11, 2015 01:55:43 PM GMT
Yes, show the code. If the code is not what a majority of us would consider to be best practice, then it should *not* hold back fixes.
Comment by External U.
6702 | December 11, 2015 01:59:06 PM GMT
If MY app ever broke because a numeric was expected to be a string, then I'd gladly fix my code. Things like this should be fixed for the sake of the language and mentioned as breaking backward compat so people can be on the lookout. I agree with the others here that we ought to be able to see Adobe's test cases on this.
Comment by External U.
6703 | December 30, 2015 09:24:19 AM GMT