Barney Boisvert demonstrated an interesting issue with CFCs on cfcdev. Consider the following code:
Alpha.cfc
<cfcomponent>
<cffunction name="test">
<cfargument name="test" required="true">
<cfoutput><br>inside the method, test is #test#<br></cfoutput>
<cfset test = "apple">
<cfreturn arguments.test>
</cffunction>
</cfcomponent>
<cffunction name="test">
<cfargument name="test" required="true">
<cfoutput><br>inside the method, test is #test#<br></cfoutput>
<cfset test = "apple">
<cfreturn arguments.test>
</cffunction>
</cfcomponent>
test.cfm
<cfset x = createObject("component","alpha")>
<cfset result = x.test("banana")>
<cfoutput>#result#</cfoutput>
<cfset result = x.test("banana")>
<cfoutput>#result#</cfoutput>
When you run this code, you would expect alpha's test method to return apple. When working with the arguments scope, we've been told that we don't have to use Arguments. in front of the variable. In fact, the debug output inside the method will clearly show that test is banana. However, note that when we change it, we don't use the Arguments scope. When we return it - we do. The result - not apple, but banana.
Something to watch out for. I tend to just always use Arguments. notation as it helps me keep clear which variables are arguments and which are function local or in the CFC variables scope.
Archived Comments
Some other people pointed out that this is a hold-over from the CFMX 6.0 days, when there was an arguments scope, but not a local variables scope. As Ray said, always using arguments will work (operates under the assumption that arguments are not local variables), but never using arguments will also work (operates under the assumption that arguments are only local variables). The trouble will only arise when you mix the two.
Once again we see why a consistent coding style is so important... :)
A-freakin-men Sean.
seancorfield wrote:
> Once again we see why a consistent coding style is so important... :)
That's true in this case, but that is not even close to the answer to solving all the problems we have with CFCs, I don't really know where to begin.
Because we're already so far gone with CFCs, and MM *can't* change them this late in the game, I reckon it'd good if we approached BD, and asked them to come up with something new and improved. <cfclass> with <cfmethod>s or the like. Where variables are local to where they're set. And scope resolution work in a meaningful and understandable way. Constructors. Static methods. Imports. The sky is the limit. We have so many great OO languages to take the lead from.
Working with CFCs, especially if you use them heavily, is becoming more and more of a headache the more we learn about its intricacies. Obviously they're better than not having anything at all, but we're in no-man's land. Not OO, not procedural, just a half-baked idea by some guys who weren't told, or didn't attempt, to come up with something concrete and solid.
BD help us! <cfclass>? Lead the way!!
Sorry you feel you have to make comments anonymously when you're attacking the engineers who designed and implemented those new features in ColdFusion MX...
Sounds like you really want to program in Java, not ColdFusion?
If ColdFusion became simply an alternative syntax for Java, there would be little point in using it because you'd get all the complexity of Java combined with the verbosity of a tag-based language.
seancorfield wrote:
> Sorry you feel you have to make comments
> anonymously when you're attacking the engineers
> who designed and implemented those new features
> in ColdFusion MX...
Yes, sorry about that. To the MM guys: sorry! Ignore me, I'm just ranting and raving like a madman.
> Sounds like you really want to program in Java, not ColdFusion?
Gosh, not at all.
Surely we can strike a balance between the logic of Java and the rapid-development of CF?
If we're going to write fully fledged OO applications, as the CF-OO-CFC advocates would like ("CF developers should move to OO" etc.), we need the tools to do so.
Again, apologies.
My team are - for the most part - hardcore OO developers used to Java and C++ and they're able to build fully-fledged enterprise-class OO applications using CFMX.
No one claims CF is perfect (nor is Java, nor C++ etc) but it's perfectly good enough...