Wow! I take my eyes off CFCDev for a few hours and look what happens! :)

On Mar 19, 2004, at 10:36 AM, Barney Boisvert wrote:
First, people should consider the 'arguments' scope a depricated carryover from 6.0 that was required to not break code, but should NEVER be used.

I think that's a *really* misleading thing to tell people. "arguments" is a scope and works just fine (in both 6.0 and 6.1).


In 6.0 there wasn't a local variables scope

Correct.


so any guidelines that went along with the 'arguments' scope can't be applied to 6.1 where there is a local variables scope.

(a) has nothing to do with (b) in my opinion. You can certainly say that "any guidelines that go along with the 'var' keyword can't be applied to 6.0".


In other words, 6.0 arguments and 6.1 arguments are effectively two completely different things.

No, they're exactly the same. What is different, is that 6.1 now has a local var scope and - for the purposes of backward compatibility - the arguments scope is copied into the local var scope on entry to the function. This also means that unscoped arguments are found by direct local lookup in 6.1 rather than by scope stack searching (as happened in 6.0) so the result is faster lookups of (unscoped) arguments.


With that statement, it becomes apparent that using the 'arguments' scope for ANYTHING with 6.1 is a bad idea.

I totally disagree with you, I'm afraid.


<cffunction name="isInt" returntype="boolean">
  <cfargument name="num" type="numeric" />
  <cfset var num = int(num) />
  <cfreturn num EQ arguments.num />
</cffunction>

But that is absolutely no different to this implementation (except for the 'evil' name clash and the lack of proper scoping in 'int(num)'):


<cffunction name="isInt" returntype="boolean">
        <cfargument name="num" type="numeric" />
        <cfset var chopped = int(arguments.num) />
        <cfreturn chopped eq arguments.num />
</cffunction>

In fact, if you religiously treat arguments as living in the 'arguments' scope and therefore qualify all references to them, there's even a (slim) argument for saying this code is perfectly reasonable:

<cffunction name="isInt" returntype="boolean">
        <cfargument name="num" type="numeric" />
        <cfset var num = int(arguments.num) />
        <cfreturn num eq arguments.num />
</cffunction>

All I did was change the name of the local variable - which shows that there's no conflict of lookup here. This says you have a local variable 'num' and an argument 'num' and they are two different entities (which in fact they are).

Regards,
Sean

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.


CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to