Scope order: local vs argument

[minli98]

Hi,

According to http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec09af4-7fdf.html, LOCAL variables take precedence to ARGUMENTS variables.  However, when I access an unscoped variable in a CFC function that is available in both LOCAL and ARGUMENTS, I get back the ARGUMENTS scope.  Why is that?  I am using CF 9,0,0,251028.

<cfcomponent>
   
    <cffunction name="testFunction" access="public" returntype="string">
        <cfargument name="x" default="argument">
       

        <cfset LOCAL.x = "local">
       
        <cfreturn x />

    </cffunction>
   
</cfcomponent>

<cfset obj = createObject( "component", "component.Test" )>

<cfoutput>#obj.testFunction("argument")#</cfoutput>

The output I get back is "argument" instead of "local".

The other thing that I find weird is that if I replace

<cfset LOCAL.x = "local">

with

<cfset var x = "var">

I get the error message "X is already defined in argument scope".

[Adam Cameron.]

My guess would be "bad implementation on the part of Adobe", at least on the basis of you evidence, anyhow.

Have you got a repro case? Maybe raise a bug with them.

--

Adam

[Steve Sommers]

Hmm, I have never heard of the "local" scope. Are you sure the doc is not referring to <cfset var x = "local" /> as being a local variable? Try changing your example to the following:

    <cffunction name="testFunction" access="public" returntype="string">
        <cfargument name="x" default="argument" />
        <cfset var x = "local" />
        <cfreturn x />

    </cffunction>

[minli98]

Hi Steve,

Local scope was a new addition to CF9 and is supposed to be the equivalent to doing var varName inside a CFC function.

Anyway, I found this thread at houseoffusion forum that confirms that local scope is buggy.  http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:61285

ML

[minli98]

Hi Adam,

The result of my experiment was so unexpected that I was sure that I was missing something.  If it is indeed a bug, it is a glaring bug (especially since CF 9 has been out for a few years).  Can you or someone also confirm that it is a bug?

Have you got a repro case? Maybe raise a bug with them.

Sorry, I am not familiar with your terminology.  What is a repro case?

Thanks,

ML

[-__cfSearching__-]

Can you or someone also confirm that it is a bug?

The output I get back is "argument" instead of "local".

I can confirm the same results. Though I was more surprised you were even able to declare the same variable name in both scopes. That was not possible before the explicit function LOCAL scope was introduced. You would just receive an error like the one you posted. I do not see much gained by allowing it, except maybe confusion. So perhaps that is the real bug. Anyway, if you want to report it here is the url: http://cfbugs.adobe.com/

What is a repro case?

A small, stand-alone, snippet of code that reproduces the issue.

[minli98]

-==cfSearching==- wrote:

Though I was more surprised you were even able to declare the same variable name in both scopes. That was not possible before the explicit function LOCAL scope was introduced. You would just receive an error like the one you posted. I do not see much gained by allowing it, except maybe confusion. So perhaps that is the real bug.

Since Adobe has an article about scope order, I would think that we should be able to use the same name for different scopes.  Not a good practice maybe, but it should not throw a variable name conflict error.

[-__cfSearching__-]

I would think that we should be able to use the same name

or different scopes.  Not a good practice maybe, but it

should not throw a variable name conflict error.

Yes, traditionally CF has allowed the declaration of the same variable name in multiple scopes .. except within functions. It may have been a practical limitation in CF8 which had more of an "unnamed" local scope. But whatever the reason, it was not allowed. So that variable conflict error is certainly nothing new.  Like I said, I am not sure I see any benefit in allowing this within functions. However, since the two earlier statements are essentially doing the same thing, it would be nice if they both produced the same results at least ...

Yes, I think there is something wonky going on. But it is a matter of opinion what that something is ...

My opinions will not buy you much here 😉 So if you feel there is a bug, file a bug report.

Message was edited by: -==cfSearching==-