Should Centaur have a CFScript version of every tag?
My last post about my structparam function had me thinking about what tag stuff you can't do in CFScript without writing some sort of wrapper function. I know from the CFUnited keynotes Adobe has some kick butt CFScript stuff up their sleeve. I know this is probably a can of worms, but what's the chance they would go all out and give us a CFScript equivalent for just about everything from sending mail to cfquery?
I think it would be cool to have a new file format called .cfs for ColdFusion script and you could fill it with script without having to use CFScript tags. Heck, I'm probably going overboard here... I already talked about why we want some stuff for the wrong reasons. What do you guys think? How far should CFScript go? How far is too far?
On the plus side if Adobe market CF9 with the ability to use pure scripting (no tags) then it may earn extra respect from people who didn't take a tag based language seriously. It would make it easier for developers who know other scripting languages to try their hand at CF, or adapt if their boss puts them onto a CF project.
Then again, if pure scripting becomes a feature of CF9 it will send out mixed messages and perhaps turn away those who would be attracted to a tag based language. Swings and roundabouts. I guess the question is, does CF need to radically change with the times, has its market and user based changed? I believe it has.
There are as @Gary mentioned many who don't take a tag language seriously. Are they wrong, yes IMO. Yet, we can't get them to look at CF for the same reason. Growing the community has potential with at least a near complete script. Of course opinions vary on this.
http://www.cflib.org/library/CFMLLib
Of course, I am saying that in a vacuum. It would be really nice to know what other potential feature(s) I would have to give up to get that.
We use CFLib as a stopgap now. Yet, having abort(), throw(), dump() and a few others would be great. IMO we should do our queries in CFCs. (My style note.) If that is true inside CFC just create a function for the query and move on. Yet, if the only thing that held all these tags from going into CF8 as script was CFQuery... then just like we pass in arguments as a structure into tags... make this tag the exception and require passing in a structure of name/value pairs into the query(parameterStructure) request. :)
I don't think it is necessary to have a whole new file type like .cfs. I agree with others that the ability to switch between the two is quite nice.
@Ryan: you have a good point about wanting it, but not at the cost of new features. I've heard Ben Forta say a lot that for everything that goes into a release, something else has to come out.
However I think we are where we are with the balance of CFML/CFScript, and it's perhaps not the best usage of people's time porting CFML-only functionality to script, especially as most tags can be very quickly implemented as a UDF using CF8's attributecollection functionality to quickly transplant function arguments to tag attributes. This is different from my position prior to CF8, as it was much more difficult to implement function versions of tags.
I don't see this argument being one of CFML vs CFScript, I see it as "tag-based" vs "function-based".
What I might ask of Adobe is that - with new work - they give some more thought to what's best implemented as a tag, and what's best implemented as a function.
To me, the only things that should be implemented as tags are pieces of functionality which lend themselves best to being approached in a tag-like way. Examples of this are CFQUERY, CFSAVECONTENT, CFXML, etc: these demonstrate situations in which the tags "wrap" other text / tags, which - I think - is much easier to do with tags than function calls. If some functionality does not "fit" that sort of processing, I think it should be implemented as a function. The default should be "implement as a function".
Obviously any new control statements (for example the FINALLY construct, or CONTINUE keyword) should be implemented as both tags and script. Control statements and other syntactical (not functional) constructs are the real area that there's a CFML vs CFScript position to have.
I would like the position of CFML (or "the ColdFusion Language", as it's not all mark-up... not even the majority of it) to shift from "tag-based" to "tag-enabled".
I think the defensive position that CFML is easier for people porting from HTML-only is a specious one. No-one's going to get anywhere if they use only tags (and no function calls) on their website, so - like it or not - they're going to have get up to speed with function-calling, SQL, JavaScript and what have you pretty darn quickly.
I also would be surprised how many people are still coming from HTML-only and expect to use CFML in a commercial way. I wouldn't hire a "developer" who had only HTML experience. Who else here would? On the other hand there's the "hobbyist" out there too.. however in my experience, hobbyist developers are usually more savvy than commercial-only developers (people who write code 9-5, M-F and don't have any interest in doing it other than that). But I am also sure Adobe know more about their market than I do!
--
Adam
It would still take some time, and *each element* of the refactored functionality would need to be put through the testing wringer: unit tests, usage tests, etc.
En masse, that's quite a chunk of work; it's not just a matter of shrugging off the outer tag-based interface to the underlying functionality and adding a CFScript interface to it (and that's it), like you seem to be suggesting.
Also some tags - CFCHART for example in which outer tags need to interact with inner tags - will probably require a bit more work that that.
It's not trivial. It's not immense, but it's not trivial.
--
Adam