A couple days ago Ray posted a screen shot from Adam L showing some new cfscript syntax in Bolt. I personally am excited about it. I certainly don't use cfscript for everything I code, but I definitely have gotten to the point where all my business logic is in cfscript. I just think it is cleaner. I have some questions of my own out the new Centaur syntax though. Here is my best stab at what the code in the screen shot looked like:
[code]component
{
	public void function init(){}

	public query function getData(mediaid)
	{
		var q = new query();
		q.setDatasource("cfartgallery");
		q.setSQL("select * from art where mediaid = :mediaid:");
		q.addParam(name="mediaid",value=arguments.mediaid,CFSQLTYPE="CF_SQL_INT");
		return q.execute();
	}
}
[/code]
The first thing that I noticed was that the file name in the screen shot appeared to have a .cfc extension and that the first line of code was simply the word "component" followed by a curly open bracket. It looks like the cfscript tags were unnecessary. The second thing I wondered is if the argumentcollection trick would still work with the script version of tags. And would you use it as parameters to the constructor or would there be a method to set them?
[code]var q = new query(datasource="cfartgallery",SQL="select * from art where mediaid = :mediaid:");

or

var params = {};
params.datasource = "cfartgallery";
params.SQL = "select * from art where mediaid = :mediaid:";
var q = new query(argumentCollection=params);

or

var params = {};
params.datasource = "cfartgallery";
params.SQL = "select * from art where mediaid = :mediaid:";
var q = new query();
q.setArgumentCollection(params);
[/code]
Of course, I'm not sure what you would do with the addParam. Create a queryParam object, populate it first, and then pass in that object as your param? That sounds like a lot work, but it's basically what I would expect in ActionScript if this were flex. That being said, sometimes I appreciate MXML for the simple way you can define and nest objects via tags. Hmm, sounds like another language I know... The next thing I thought of is how cfscript would handle stuff like the hint, required, type, displayname, output, returnFormat, or secureJSON attributes that don't always seem to have a precedent in ECMA script. (Well, AS let's you declare you types as function(var1:type1,var2:type2)) Further to that point, a lot of frameworks (like ColdBox) depend on the random stuff you can stick into cfcomponent and cffunction tags like cache="true" or _autowire="true" and then get back out with getMetaData(). That would really suck to not be able to use any of this if you were married to a framework dependent on the random meta data that CF's tag-based format allows you to stick in. Another thing is is the cfproperty tag. Some frameworks use cfproperty tags for dependency injection as well as generic getter/setters and validation. CF9's new ORM stuff is supposed to be defined by the cfpropery tags in your component. How will these be handled in script? The final thing I thought of is how some of this code is a fundamental break from the OO mentality of CF thus far. I'm not talking about the fact that it is script instead of tags, but rather that the language core had objects with methods you call on them. In Java you do object.toString(), but in CF you do toString(object). In JavaScript you do myString.toUpperCase(), but in CF you do ucase(myString). ColdFusion functions have always existed there on the page for you to pluck out and use. They didn't "belong" to the objects. There are CF datatypes that support stuff like myQuery.sort(1,true) and myArray.AddAll() but those are undocumented "features" of the underlying Java. The line of the example code that said q.execute() seems very Java-esque to me. Maybe that is because a Java Prepared Statement has an execute() method. I guess we'll see how this pans out. I like where it is going, but I don't think I want CF just to turn into Java.