> I have a fairly major concern with this.  Why is isDefined() returning
> true?  It should be returning false, as the scope "variables" has been
> specified as part of the whole variable name.

isDefined() determines whether you can validly use the variable name
specified as its argument, i.e., if isDefined("some.variable.name")
then you can put some.variable.name in your code and not get an
undefined variable error.

isDefined() uses the standard CF scope lookup rules that have been
around for a long, long time.

> The whole point of scoping variables is to stop functions like
> isDefined() going off and doing its own thing.  Its should only be
> checking to see if test exists in the variables scope and not whether
> "variables.test" exists in any scope, including a "null" scope.

No, isDefined() mirrors the built-in lookup rules. Scoping variables
helps you avoid conflicts when you have the same variable name in
multiple scopes - and in general when you scope a variable, you know
the variable exists in that scope.

In other words, we tend to think in terms of
structKeyExists(someScope,"myVar") even tho' that is a stricter
definition than isDefined("someScope.myVar") - and it is the latter
that reflects how CF really treats someScope.myVar in code.

Bear in mind that the difference is only there if the variable is
*not* defined where you expect it to be (i.e., if structKeyExists()
returns false).

> This would means that scoping is not really taken into account by
> coldfusion, other by pure luck that functions like isDefined() look in
> the null scope first.

Sure, scoping is taken into account - and there is no "null scope".
Everything lives in a scope. The lookup rules are a convenience so
that you (mostly) don't have to specify "variables." everywhere.

> If isDefined() is not taking scopes into account, does it keep going
> until its checked all scopes or does it stop searching when it hits the
> first occurance?

First off, it *is* taking scopes into account - according to the
variable lookup rules - and secondly, yes, it stops as soon as it
finds a defined path to a variable. That's why I said the difference
is only visible for *un*defined variables (or where a variable is
defined in a scope other than the 'closest' scope).

> If I'm using StructKeyExists() I need to check whether the struct that
> I'm checking in exists before I check for the keys existance as it
> throws an exception if the struct doesn't exist, so I would have;

Not really because in most cases you already know the struct exists -
especially if it's a scope name:

> <cfif IsDefined("variables") AND
> StructKeyExists(variables.variables,"test")>

That's wrong on two levels:
1. variables is *always* defined because it is a scope
2. if variables.variables doesn't exist you'll get an exception!

> <cfif IsDefined("variables.variable") AND
> StructKeyExists(variables.variables,"test")>

You mean isDefined("variables.variables") - but you could write that:

<cfif structKeyExists(variables,"variables") and
structKeyExists(variables.variables,"test")>

(assuming you don't also want to check isStruct(variables.variables)...)

> <cfif IsDefined("variables") AND StructKeyExists(variables,"variables")
> AND StructKeyExists(variables.variables,"test")>

Yes, except that isDefined("variables") is always true by definition.

> hopefully you see the point that because you
> have to use isDefined() to check to see if your struct exists

No, that's the whole point - you *don't* need to use isDefined()
because you *know* the built-in scopes exist.

> I understand what is happening here, but it means that variables.foo.bar
> doesn't exist either, that "foo.bar" can only be referenced by
> variables['foo.bar'] and CF is letting people create variables with
> invalid characters in their names.

CF has always allowed variables with . in them. In fact that was one
of the specific differences between CF5 and CFMX:

CF5:
<cfset foo.bar = 42>
Creates a variable called foo.bar

CFMX:
<cfset foo.bar = 42>
Creates a variable called foo as a struct with a key called bar
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to