Jul 06
Over on the New Atlanta blog Vince Bonfanti presents a compelling argument for introducing strong typing to CFML without making big sacrifices. I’ve certainly never thought about what goes on under the hood even for the most simple of code….boy I must be keeping my CFML engine busy - which by the way is BlueDragon.NET 
July 5th, 2006 at 11:39 pm
Vince seems to want to turn CFML into a verbose version of Java / C# which would obviate any of the benefits of CFML…?
July 6th, 2006 at 3:32 am
Sean, here’s a quote from my blog post:
"by introducing strong typing and related enhancements to CFML it will be possible create a runtime (BlueDragon or CFMX, or whoever) that performs better and results in more reliable and better quality CFML applications. I believe this can be done without affecting the ease-of-use and Rapid-Application-Development (RAD) advantages that CFML has over other web application languages."
I don’t believe adding strong typing to CFML turns it into a "verbose version of Java / C#"; for example, CFQUERY is still much more succinct than any equivalent Java / C# code, and the same is true for most CFML tags. The syntax enhancements I’m proposing (and I’m open to alternatives) are fairly minor, and would be optional.
Can you elaborate on why you think adding optional strong typing "obviates any of the benefits of CFML", since I really don’t see how that could be? I’m very interested in hearing your opinion on this.
Regards,
Vince
July 6th, 2006 at 4:24 am
from what Vince was saying, adding a simple type="" attribute to a cfset seemed fairly trivial if its going to offer increased performance to my applications and from one of his previous posts it would be something that could be turned off/on at will.
We use cfqueryparam to bind data types in SQL to increase Db performance - what’s the difference here? If it increases performance at no extra cost what’s the issue?
July 6th, 2006 at 7:25 am
Well, Sean, CF’s already got typing on:
<cfparam>
<cfqueryparam>
<cfprocparam>
<cffunction>
<cfargument>
queryNew()
QoQs in general
javacast()
…
Makes good sense to me to make it an option on <cfset> too, should people want to do such things. And I know from various CF beta programmes and wishlists, there’s a bit of community backing for it too.
I think Vince’s suggesting of a <cfsetting> option to enforce it is a nice one, too.
–
Adam
July 6th, 2006 at 1:33 pm
If folks want strong typing and "more performance", why not just drop into Java for the critical portions? I think the push to make ColdFusion more "Java-like" is a mistake.
It seems to me that folks already complain ColdFusion’s syntax is unwieldy compared to Java / C# and adding more attributes just to make ColdFusion behave "just like Java" is only going to make it more so (for the record, I don’t agree the syntax is unwieldy - I write all my code in tags rather than script, Fusebox 5 verbs excepted).
I find the obsession with performance to be… well, I just don’t understand it. Everyone seemed to find performance the most exciting thing about duck typing, much to my chagrin, and now folks are excited about going to the opposite extreme with types for the same thing…
I don’t really want to get into a debate about it - I’ve made my position on this whole performance obsession pretty clear on my blog.
September 19th, 2006 at 1:43 pm
Can’t believe I missed this post (for 3 months - sorry guys!).
Also can’t believe with all the hype about dynamic languages these days that anyone would want to enforce strong typng in CF. What can you go with dynamic typing? Well, for starters, a lot of metaprogramming (base classes and the like) is impractical with strong typing.
We’ve always known strongly typed languages with compilers made it harder for average programmers to mess up, but please leave us our dynamic typing so the rest of us can write some interesting code!
Strong typing without a compiler and IDE support - seems like the worst of both worlds!