tracker issue : CF-3822362

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

CFScript 2.0

| View in Tracker

Status/Resolution/Reason: Needs Review//

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

Created: 09/11/2014

Components: Language

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 15

See http://cfmlblog.adamcameron.me/2014/09/cfscript-20.html:

{quote}
GaryF mentioned this in a comment:
I believe a solution has to be creating a new, clean syntax which can be used within tags like this: <cfscript version="2"> </cfscript> Adobe would have to create a new interpreter but it just kicks in if version=2 is specified.
Yes. This strikes me as quite a nice idea. One could either specify the version in the tag, or have some compilation options somewhere which tell CF to which version to default. This way, there doesn't need to be any backwards compat considerations: one just picks which level to run on.

Also both vendors can get rid of their shitty generic CFScript solutions, plus fix other things that have crept in over the years (writeDump() instead of dump(); writeOutput() instead of just output() even); implement everything that looks like a function as as a function ("ColdFusion: some built-in functions aren't actually functions. It seems."), and - really - implement the scripting side of CFML the way it should always have been implemented: comprehensively, carefully, thoughtfully and thoroughly.

Another upside here is that they could implement an annotation at the start of a CFM file along the lines of @scriptversion = 2 or something, and have script-only CFM files too. That said, CFMs should be for views; most code should only be in CFCs I guess, but the CFC would need the same annotation too.

The could even extend this to the entire language: have a <cfprocessingdirective version="2"> or some other sort of annotation in a CFM file to flag which version of the tag compiler to use. This way we could get rid of most of the tags and only continue to maintain view-appropriate ones, and fix up some stuff that's never been great but we've been stuck with because of backwards-compat excuses.

Rakshith indicated that ColdFusion 12 would be less cautious with backwards compatibility issues... this might be the way to go with this.
{quote}

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

Watson Bug ID:	3822362

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

Attachments:

Comments:

+1 This makes a lot of sense and would definitely move things forward.
Vote by External U.
10933 | September 11, 2014 04:50:12 AM GMT
I think this is the best way to move the language forward. It would allow for a full reconsideration of every aspect of CFScript - all the functions, and the way the language is constructed (semicolons for example - necessary or not??) This approach could even be extended to CFML. I would like to see this happen. Make it so!
Vote by External U.
10934 | September 11, 2014 08:47:31 AM GMT
Very much in favor of this. An update like this could revitalize the language while not sacrificing legacy work.
Vote by External U.
10935 | September 11, 2014 08:58:16 AM GMT
CF needs this fresh start
Comment by External U.
10926 | September 11, 2014 09:17:36 AM GMT
CF needs this fresh start
Vote by External U.
10936 | September 11, 2014 09:17:54 AM GMT
Casting my vote here too. Now that cfscript v1 has auto-generic tags->script you can focus on a fine tuned cfscript v2 where each aspect can be closely analysed and handled in a purposeful way. I would add that this will only work if you include the dev community early and often. Not just management from the big gov shops you sell a ton of licenses to, but the actual devs in the trenches that wish push the language forward. Join the #coldfusion IRC channel, participate in Stack Overflow questions, CF forums, etc...; solicit feedback on ideas *before* writing a single line of code and be prepared to scrap an idea if the community advises against it.
Vote by External U.
10937 | September 11, 2014 10:09:21 AM GMT
CFScript is an inconsistent mess. No new developer should have to learn this conflicting, illogical, botched, scripting language. V2 implemented this way will guarantee backward compatibility and wipe the slate clean to attract newcomers to CF and utilise it based on what they know of more elegant syntax such as from JavaScript. Tagged based scripting is a dead-end these days and learning CFScript v1 is a bad career move. It's time Adobe think of the future, stop adding poorly implemented features that no one wants to use and go back to the drawing board and get the language right without having to throw the baby out with the bath water.
Vote by External U.
10938 | September 11, 2014 05:06:24 PM GMT
Agreed. I want to switch to script, but the current implementation is a joke. Its plainly obvious that it was a patch job and not a serious attempt at improving the language. This type of code cfdbinfo(type="tables", name="info"); should be info = dbinfo(type="tables");
Vote by External U.
10939 | September 16, 2014 02:23:35 PM GMT
I would LOVE to see a well thought out and well-implemented CFScript!
Vote by External U.
10940 | September 16, 2014 07:43:32 PM GMT
Absolutely make sense, ColdFusion need to beautify itself
Vote by External U.
10941 | September 17, 2014 11:23:20 AM GMT
I concur with others - cfscript done correctly is the next logical step in the evolution of the product to maintain any competitive advantage moving forward. The current script implementation is still too sloppy and needlessly divergent from the norms every other language follows.
Vote by External U.
10942 | September 17, 2014 12:13:44 PM GMT
This would be a nice way to fix cfscript without having to worry about backward compatibility.
Vote by External U.
10943 | September 17, 2014 02:25:21 PM GMT
With each new release, cfscript has become more inconsistent, incoherent and not to mention, hard to find decent documentation on. This should be a priority for the next release to clean this up and make it a primary feature of the language and not just patched-on updates that have no rhyme or reason to them.
Vote by External U.
10944 | September 17, 2014 02:25:28 PM GMT
+1 ......................
Vote by External U.
10945 | November 24, 2014 04:03:17 AM GMT
Hey, if Hollywood can reboot the Batman franchise 3 times in 25 years, then Adobe should be able to reboot cfscript once in 20 years!
Vote by External U.
10946 | November 24, 2014 09:53:38 AM GMT
................................................................
Vote by External U.
10947 | July 01, 2015 03:00:45 AM GMT
So... almost three years on... hows that "Needs Review" going?
Comment by Adam C.
10927 | August 02, 2017 07:07:32 AM GMT
Hi Adobe, +1 for an update. This ticket has 15 voters, and no comment from Adobe. Is this targeted for Aether? Thanks!, -Aaron
Comment by Aaron N.
10928 | August 04, 2017 08:55:30 AM GMT
I suspect it's disappeared _into_ the aether.
Comment by Adam C.
10929 | August 04, 2017 08:58:05 AM GMT
The priority is set to Trivial. Hmm. I would argue that stuff like the API Manager is trivial and a better scripting engine is critical.
Comment by Gary F.
10930 | August 04, 2017 11:12:55 AM GMT
Trivial to CFML devs? No. Trivial to Adobe's bottom line, which is all they care about (and rightly so, in a short-sighted sort of way)? Yes. PHBs don't sign off licences on language features (that they won't understand); they sign-off on shinyshiny like API Managers.
Comment by Adam C.
10931 | August 04, 2017 11:17:07 AM GMT
I would say that features like this are not trivial to the bottom line. Developers don't pay the bills directly, but without their voice within the company, nobody is going to give CF a second look much less pay $8k+ for the APIM.
Comment by Stephen W.
10932 | August 04, 2017 11:40:19 AM GMT