Another idea occurred to me in bed last night as I was dropping off to sleep. To help us cope with the current situation and avoid having to go back to the top of the function everytime a new variable is required:

Declare <cfset var my = StructNew()>. Then use this structure for any local simple variables or queries: <cfquery name="my.qryNew"…>, <cfloop index="my.i"….> etc.. You might still want to declare separate var scope variables for your return structure or other complex objects.

This idea came out of what Jaime Metcher said above about the way Perl uses ‘my’ as a way of declaring local variables.

You wrote:

"See i think they can modify the var keyword without breaking everyone’s code. If they basically deprecated the var keyword so it did nothing i.e.: &lt;cfset var myvariable="hello world"&gt; is the EXACT same thing as &lt;cfset myvariable="hello world"&gt; how many apps would that actually break? I’d be willing to bet it would break exactly zero."

Actually, ever single CFC I’ve ever written would break.

You see I use the "instance" struct variable as a way to declare private data for my CFCs. All my getters and setters have keys in the "instance" struct.

So, my code looks like:

<cfcomponent>
<cfset instance = structNew() />
<cfset instance.private = "Dan Switzer" />

<cffunction name="getPrivate" returntype="string">
<cfreturn instance.private />
</cffunction>

<cffunction name="setPrivate" returntype="void">
<cfargument name="arguments.input" />
<cfset instance.private = arguments.input />
<cfreturn />
</cffunction>
</cfcomponent>

If all variables suddenly become local variables only, I have no way to access the "instance" variable. I don’t want to use the "this" scope, because that’s a public property accessible from the pages that invoke the component. I want my data private and only accessible to my CFC logic.

So, while the "var" keyword definitely feels kludgey, it has its uses. Yes, they could have solved it a different way, but that road was crossed along time ago.

As Mark Mandel pointed out, I just wish I could "var" a variable anywhere w/in my function (like I can in most other scripting languages.) That certainly would help me to keep my bugs down from unscoped variables.

Whereas if you had done this:

<cffunction name="getPrivate" >
<cfset instance = structNew() />
<cfset instance.private = "Dan Switzer" />
</cffunction>

Then the instance variable *should* be local to that one function. As if you had typed: <cfset var instance = structNew()/>

Since we’re just dreaming here, to make things even more fun…

<cffunction name="getPrivate" >
<cfset instance = structNew() />
<cfset instance.private = "Dan Switzer" />
<cfreturn this/>
</cffunction>

I think when a function returns THIS, then the local (function level) "instance" variable should become local (CFC level, still not public from the calling template). In other words when you return THIS it should work just like when you defined it before cffunctions.

Granted, this is all just a pipe dream and it’s never going to happen.

Well… not with that attitude.

The problem, as I see it, is that the setter by default would set a local variable–not the global variable. How is CF supposed to know that you want to set the global and not a local variable? Anything you do to automate the process brings in scoping issues.

At least w/the var keyword you have explicit control over whether the variable is global or local to the current function.

I guess the thing that doesn’t bother me is that most other scripting language would behave this way–which is probably why Macromedia choose this method. The problem is, CF isn’t really like most other scripting languages.

A variable cfset above the functions is local to the CFC. A variable set inside of a function checks to see if it already exists at the CFC level, if so it updates the value and keeps it at that level. If it does not exist at the CFC level it automatically gets var’d behind the scenes.

Is this really any more complex than a single (maybe a few) if statements? I can picture how to do the logic in my head using structkeyexists().

If CF *were* like other scripting languages why would we pay $1200 for a copy of it?

I think the approach that you are suggesting makes thing less consistent. It smacks of having the language make decisions/assumptions for me.

Not only that, but it could still break code. Many times variables-scoped variables are first set in an init() method. Now, mine are all explicitly put in variables scope for clarity, but there is bound to be plenty of code where that isn’t the case.

Steve (Bryant), CF makes all sorts of decisions and assumptions for you. If I thought hard enough for 5 minutes I could probably list out 50 assumptions it makes for you.