The VAR keyword is idiotic

I agree that this is a pain at times and infact it's extra coding, but would adding this feature require extra parsing from the cf engine? Surely there must be a reason why they require us to add the 'var' manually... isn't there??

Brain (I prefer that name over Brian)-

Yes it would break existing code if someone is making use of turning it off (not using it). That's why I ask the question "do you ever want to NOT use it?"

I'm not convinced anyone is NOT using it... on purpose. Plenty of people are not using it by accident. Like me. Whoops, I just found another one.

Am I wrong in thinking that the same thing can be done with the request scope?

Steve: no. The whole point of instance data for an object is that it is private and encapsulated within the object. This is where the methods come in: no external code manipulates the instance data of an object directly. They send messages (i.e. call methods) on the object to ask it to do something.

I agree with what you say. I'm not sure if the functionality should be fixed for legacy reasons.

My biggest problem is that the var keyword is inconsistent with the rest of the CF Language. There is nothing else like it in the language.

I'm sure the CF team is cautious about making changes that affect how things work, though. I do not expect the var keyword to go away.

My one addition to your request is that the "un-named function local" scope be given a name, perhaps "local".

So this:

<cffunction name="myfunction">
<cfset local.myvariable="hello world">
</cffunction>

is the same as this:

<cffunction name="myfunction">
<cfset var myvariable="hello world">
</cffunction>

Then we 'experienced developers' could go back to blaming all the var scoping problems on people who do not properly scope their variables.

I don't think it's not a good idea for you to stop using double negatives is all.

Not that it helps the situation but here's some historical background:

In a .cfm file, foo = 42; is identical to variables.foo = 42; and thereafter references to foo are identical to variables.foo. And variables is the page scope.

Since that's so common to CFers, the thinking was that CFCs should work the same way. variables is the "page" scope - shared between functions in the CFC - and unqualified references use the variables scope.

In particular, in CFMX 6.0, that was your *only* choice.

In CFMX 6.1, a new function-local scope was introduced and, to preserve backward compatibility and the core axiom of foo == variables.foo above, a new declaration syntax was introduced, var.

There's a lot of code out there that does *not* use variables. as a qualifier for variables-scope names in CFCs and that code would break if you changed the lookup rule.

Having said that, I agree that inside CFCs, we more usually want new variables to appear in function-local scope instead of variables-page scope and it would be nice to have an option somehow to change that default behavior. Either through a server setting (in CF Admin) or cfprocessingdirective or maybe as an attribute on cfcomponent and/or cffunction. The latter has the advantage of granularity so you could migrate code function-by-function to the new style although, technically, the cfprocessingdirective would be the "right" approach since this is a compile-time behavior change (and still allow you to change the behavior on a per-file basis to maintain compatibility with third-party CFC code).

"I'm not sure i follow Brian. I have a good understanding what the "this" scope does currently, but what is it doing incorrectly?"

The THIS scope is public, which means any external code can call <cfset myCFC.someThisScopeVar = "" /> and modify the internal state of the component directly, without going through a method. The entire point of encapsulating the internal state of a CFC is to hide the internal implementation of the CFC and force all client code (anything that uses the CFC) to go through a method call to have the CFC do anything. That includes modifying private variables.

The whole reason no one uses the THIS scope is because it is public and lets any client code modify the CFC's internal state directly. This blows away the whole point of making internal object data private and forcing client code to use the object's API (its public methods). Make sense?

Oh. I see. Yeah, that's no good.

Although that isn't my reason for not using the THIS scope. I just haven't come across why the THIS scope would make my code easier to read/understand. That's my biggest concern.

You guys are forgetting in your fever of CFC talk that the <cffunction> tag can be used in a CFM page. As "function" can be used in the <cfscript> tag.

God knows why one would want to have a function touch a "variables" variable. But it is possible. So with this in mind I do not think "VAR" will be taken away.

LOL... I am talking about the standard idea of what an object is nearly everywhere but in CF. (And I like CF objects... and as much as I like CF would like to see a more standard object.)

Standard concept: most languages provide getter/setter functions on objects. Can you tell me how to set a "read only" value for the "This" scope? No, of course not. You can in PHP, ASP, even in Flex! Yet, there are technical difficulties that prevent it in CF. In fact it would be great if when we set a value it called the setter automatically... WITHOUT calling a method when the "standard" for UML is setting or getting a value with the "attribute". (How are we supposed to use common UML tools to design CF objects when our public variables lack common read/read-only type functions?) ... and I do like how PHP and Flex let you set a function to automatically handle the set function of a class attribute set.

Simple solution.

<cfset var local = structNew() />

<cfset local.anotherVariable = 'hello' />
<cfset local.anotherStuct = structNew() />

etc, once you have the initial var, all local. vars are local.

Sure. Add an attribute to cfprocessingdirective, and add another scope ("CFC" or "Private") that acts like an un-var'd variable does now. Then fully deprecate it in CF 9 or 10. That would work for most of us.

You can also use the arguments scope as a "local" scope. As far as i can tell it's thread safe and does not need to be declared in every function.

Yeah i agree. It does feel like cheating.

There also may be an issue with this during recursion. Specifically when overwriting an arguments scoped variable. Although I'm not 100% sure about this.