From my [private] point of view, the scoping of 100% variables is a
programming extremism. When some scope is implied, there is no reason to
scope variables, unless it is absolutely necessary, like in CFQUERY-related
loops, or using functions with side effect(s). Or if this is a policy of
Non-scoped version ALWAYS runs 5-15 times FASTER than the scoped version!
This is on CF8, 32-bit, 4 CPU Dell Server, Windows 2003. Could somebody run
this on CF9 32/64 bit?
Exactly the same here under CF9.
I inverted the two loops ie: scope first and non-scope second, just in case,
and
ALWAYS SCOPE!
Quite I've been struggling with a site for a side job and no scoping
whatsoever. I'd love to discuss this with the original developer. Although the
site is such a kludge I suspect that now this person is a CF hater now.
I know several CF people who love the language and been making a living off
it for around a decade. None of them scope things nor do they even
understand what scoping is.
On Sat, May 21, 2011 at 4:52 PM, Larry Lyons larrycly...@gmail.com wrote:
ALWAYS SCOPE!
Quite I've been
I know people who have horrible code readability and been in the same teams
for 5-10 years. I have worked with a lot of different teams over the years
and most of them the readability of the code appeared to be way down on
their lists of things to be done. They quite often would state otherwise
Dave Watts wrote:
This is a mistake, unless you've actually decompiled CF or used JVM
instrumentation to verify this. It's easy to jump from interface (what
you interact with) to a conclusion about implementation (how it works
under the covers) but you really don't have enough evidence to do
I have no reason for it but this is the one thing I tend to never prefix a
scope before when referencing. I often think about it but just never have
adjusted my ways. So if I have cfquery name=qryGetData ... I do not do
cfoutput#Variables.qryGetData.ColumnName#/cfoutput instead I do
Co-Author Learning Ext JS 3.2 Packt Publishing 2010
https://www.packtpub.com/learning-ext-js-3-2-for-building-dynamic-desktop-style-user-interfaces/book
Oh, by the way Steve, I like your Ext JS book. Are you doing a revision for 4?
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Thanks Dave! I'm glad you liked it.
Please, call me Cutter. I had to start adding the rest of my name to my
signature block, a few years back, because the product team didn't know
who Steve Blades was every time I applied for ACP;)
Packt has asked me to write the book for v4 on my own (I
On Fri, May 20, 2011 at 4:54 AM, Aaron Rouse aaron.ro...@gmail.com wrote:
I know people who have horrible code readability and been in the same teams
for 5-10 years.
Granted. I should have said 'my' team. If they're working for me
they get educated quick or they're gone.
--
On Fri, May 20, 2011 at 8:47 AM, Matt Robertson websitema...@gmail.com wrote:
On Fri, May 20, 2011 at 4:54 AM, Aaron Rouse aaron.ro...@gmail.com wrote:
I know people who have horrible code readability and been in the same teams
for 5-10 years.
Granted. I should have said 'my' team. If
Curiously, I do it the exact opposite way:
cfset variables.myVariable = fubar / !--- ensure that I am
setting in the variables scope, because there could be a 'myVariable'
in another scope ---
cfoutput#myVariable#/cfoutput !--- I have just guaranteed that I
have variables.myVariable, there is
: Eric Cobb [mailto:cft...@ecartech.com]
Sent: Wednesday, May 18, 2011 01:36 PM
To: cf-talk
Subject: Re: scoping
Here's my take on it:
http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable
-scoping
Thanks,
Eric Cobb
http://www.cfgears.com
Help me make
into search mode? Also...is this negated of you use a cfset on the top of
the page (again...this is only referring to local vars.)
Eric
-Original Message-
From: Eric Cobb [mailto:cft...@ecartech.com]
Sent: Wednesday, May 18, 2011 01:36 PM
To: cf-talk
Subject: Re: scoping
Here's my take
That's kinda backwards
If you don't specify a scope in your cfset statement, then CF will
always put it in the VARIABLES scope. But, if you don't specify a scope
when calling the variable (in your cfoutput), then CF will have to hunt
down the variable to determine which scope it's in.
See, depending on what the entire CFM page looked like and it's usage along
with what brought me into the code to debug things then I personally may not
see that output as obvious. Now I look at it that way because I have
inherited code from others who just plain had zero clue about scoping
because there could be a 'myVariable' in another scope
I think CFSET always set a variable in the variables scope when no scope is
specified and do not look in other scopes.
Ie:
CFSET form.test = form.test
CFSET test = test
CFOUTPUT
form.test = #form.test#BR
test = #test#
/CFOUTPUT
This
-
From: Eric Cobb [mailto:cft...@ecartech.com]
Sent: Wednesday, May 18, 2011 01:36 PM
To: cf-talk
Subject: Re: scoping
Here's my take on it:
http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable
-scoping
Thanks,
Eric Cobb
http://www.cfgears.com
Help me make
Aha, so it is. I always thought that the cfset searched the scopes as
well. Just did the following to prove myself wrong:
cfset form.fubar = test /
cfset fubar = changed /
cfdump var=#form.fubar# /cfabort
(output = 'test')
Oivay!
On 19 May 2011 13:47, Eric Cobb cft...@ecartech.com wrote:
If
Always scope your variables!
We used to have a cf programmer around here that used to put the
variable level in the application scope. Then he occasionally put it
in session scope, occasionally in request scope, sometimes in the
variables scope, and even sometimes he would pull a query with
Yes, the real benefit is that you always know which scope is being
referenced, with no ambiguity.
Actually, there is only ambiguity for those who do not know the language they
are using and its rules by default.
There could be an ambiguity if you are using the same variables names for
There's some great stuff here, though not entirely technically correct.
Key/values placed in the Variables scope are not a part of the Request
scope. You can see this by dumping the Request scope and the Variables
scope. You will see that they are two entirely different animals (BTW,
you should
On Wed, May 18, 2011 at 12:51 PM, Eric Roberts
ow...@threeravensconsulting.com wrote:
We had a discussion at work as to whether or not we should scope local vars
with the variables. scope since that is implied in a cfset. One camp says
it is not needed because of the implicit scoping when
To: cf-talk
Subject: Re: scoping
That's kinda backwards
If you don't specify a scope in your cfset statement, then CF will always
put it in the VARIABLES scope. But, if you don't specify a scope when
calling the variable (in your cfoutput), then CF will have to hunt down the
variable
it automagically know it
is in the Variables scope?
Eric
-Original Message-
From: Eric Cobb [mailto:cft...@ecartech.com]
Sent: Thursday, May 19, 2011 07:47 AM
To: cf-talk
Subject: Re: scoping
That's kinda backwards
If you don't specify a scope in your cfset statement
Hmm.. I sort of get what you are saying, Cutter, but then it seems
like Variables is a scope that can only exist within another scope. If
there was a variables.myvars struct in session, I would say that the
myvars struct really lives in Session. Yes, it also technically lives
inside another
I wouldn't say that the Variables scope is intended to live inside
another scope, I think that it's just that it can, in the context of a
persistent object.
As noted by Ray, in the comments of my first blog post, the Variables
scope was kind of an afterthought, giving a way to access those
Hmm.. I sort of get what you are saying, Cutter, but then it seems
like Variables is a scope that can only exist within another scope. If
there was a variables.myvars struct in session, I would say that the
myvars struct really lives in Session. Yes, it also technically lives
inside another
As noted by Ray, in the comments of my first blog post, the Variables
scope was kind of an afterthought, giving a way to access those
variables that weren't explicitly in another scope (form, url, session,
application, request, client). With most of the core of ColdFusion
created prior to
On Thu, May 19, 2011 at 6:55 AM, wrote:
Actually, there is only ambiguity for those who do not know the language they
are using and its rules by default.
The penalty for being smug about your mastery of the universe is -
sooner or later - extremely painful.
Put simply, unscoped vars can
Dave,
Thanks for chiming in on this, your insight is always helpful. Most of
my thoughts there are my own theories, which must be proven (or
debunked) to be otherwise :) Your deep knowledge of the history of CF
helps to fill in the gaps of time and memory, and keep perspective (for
the
The (possible) memory leak issue does not appear to be an issue anymore.
It was submitted to Adobe as a bug for, at least, versions 6, 6.1, and
7, and seemed to have been resolved with the release of version 8 (some
profiling tests, run by others, appear to verify that fact). That said,
it's
Local scope is only implied when using cf9
On May 18, 2011, at 11:51 AM, Eric Roberts ow...@threeravensconsulting.com
wrote:
We had a discussion at work as to whether or not we should scope local vars
with the variables. scope since that is implied in a cfset. One camp says
it is not
Ray Camden has blogged about this in the past, as you can read here:
http://www.coldfusionjedi.com/index.cfm/2011/1/26/ColdFusion-and-Unscoped-Variables
In summary, there are theoretical performance gains by scoping all
variables and there are some security concerns by not scoping vars.
Both are
ALWAYS SCOPE!
Especially if someone else might have to maintain the code someday.
On Wed, May 18, 2011 at 9:51 AM, Eric Roberts
ow...@threeravensconsulting.com wrote:
We had a discussion at work as to whether or not we should scope local vars
with the variables. scope since that is
This is my outlook although I do not do something like:
cfset Variables.strBlah = something /
instead I do:
cfset strBlah = something /
But I always would do:
cfoutput#Variables.strBlah#/cfoutput
or
cfif Variables.strBlah IS something
Seems to me that is what the original OP is asking
Here's my take on it:
http://www.cfgears.com/index.cfm/2010/9/22/The-importance-of-proper-variable-scoping
Thanks,
Eric Cobb
http://www.cfgears.com
Help me make a difference this summer -http://bit.ly/i8dJvQ
On 5/18/2011 11:51 AM, Eric Roberts wrote:
We had a discussion at work as to whether
Always scope your variables, unless you have a specific reason not to. It
reinforces a good habit and demonstrates to anyone reviewing your code that
you know what scoping variables is all about. I would estimate that roughly
100% of experienced CF programmers would agree that scoping local
+1 for always scoping. Clearer to read, small performance gain, small
security gain and why not.
On Wed, May 18, 2011 at 3:23 PM, Mike Chabot mcha...@gmail.com wrote:
Always scope your variables, unless you have a specific reason not to. It
reinforces a good habit and demonstrates to anyone
I'm going to jump in on the side of variable scoping for another
excellent reason: programmers don't tend to use words precisely and
that ends up with confusion. When we say:
variables.foo = 'bar';
we are not setting a local variable. We're setting a key and value
in the variables scope which
So is there any real benefit in using or not using variables. For local
variables?
-Original Message-
From: Maureen [mailto:mamamaur...@gmail.com]
Sent: Wednesday, May 18, 2011 12:40 PM
To: cf-talk
Subject: Re: scoping
ALWAYS SCOPE!
Especially if someone else might have
into search mode? Also...is this negated of you use a cfset on the top of
the page (again...this is only referring to local vars.)
Eric
-Original Message-
From: Eric Cobb [mailto:cft...@ecartech.com]
Sent: Wednesday, May 18, 2011 01:36 PM
To: cf-talk
Subject: Re: scoping
Here's my
The other camp's argument (for the variables scope): it is not necessary so
why do it?
Eric (who is in the scope everything camp)
-Original Message-
From: John Allen [mailto:johnfal...@gmail.com]
Sent: Wednesday, May 18, 2011 03:05 PM
To: cf-talk
Subject: Re: scoping
+1 for always
Yes, the real benefit is that you always know which scope is being
referenced, with no ambiguity.
On Wed, May 18, 2011 at 6:56 PM, Eric Roberts
ow...@threeravensconsulting.com wrote:
So is there any real benefit in using or not using variables. For local
variables?
[mailto:mamamaur...@gmail.com]
Sent: Wednesday, May 18, 2011 12:40 PM
To: cf-talk
Subject: Re: scoping
ALWAYS SCOPE!
Especially if someone else might have to maintain the code someday.
On Wed, May 18, 2011 at 9:51 AM, Eric Roberts
ow...@threeravensconsulting.com wrote:
We had
In theory, yes, as ColdFusion will have to hunt through the various scopes
to find the exact variable that you're referencing.
Whether it's noticeable or not.. hard to say.
From the CF8 docs (
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Variables_32.html
):
Because
out there, do what creates the most manageable,
self-documenting code. The performance results will most likely be
negligible.
~Brad
Original Message
Subject: Re: scoping and speed
From: Charlie Griefer charlie.grie...@gmail.com
Date: Thu, December 10, 2009 9:59 am
To: cf-talk
Out of curiosity Gert, why would Railo be slower finding
#variables.foo# than finding #foo# if variable cascading is on? Is it
checking for the existence of a struct named variables before checking
the actual scope or something?
Judah
On Thu, Dec 10, 2009 at 8:40 AM, Gert Franz
According to Adobe, Yes.
http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance_04.html
Thanks,
Eric Cobb
http://www.cfgears.com
Chad Gray wrote:
If you don't scope your local variables does the page run slower?
IE. #variables.foo# vs. #foo#
Source
skype: gert.franz g...@getrailo.com
+41 76 5680 231 www.getrailo.com
-Ursprüngliche Nachricht-
Von: Judah McAuley [mailto:ju...@wiredotter.com]
Gesendet: Donnerstag, 10. Dezember 2009 20:16
An: cf-talk
Betreff: Re: scoping and speed
Out of curiosity Gert, why would
If you don't explicitly assign a variable to a scope, then it's
automatically put into the VARIABLES scope. So in your example, you could
refer to your var as foo and it would be just fine.
Having said that, it's a best practice to explicitly scope your variables to
avoid confusion, and
#foo.goo# is acceptable. I, personally, explicitly scope every variable:
cfset VARIABLES.foo = APPLICATION.foo.moo() /
#VARIABLES.foo.goo#
We also have an extremely high traffic, high utilization application, so
explicitly scoping every var helps us keep memory in check (plus makes
://www.montarasoftware.com/
V: 415-577-8070
F: 415-341-8906
P: [EMAIL PROTECTED]
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 29, 2002 6:04 PM
To: CF-Talk
Subject: RE: Scoping variables
However, there are currently some bugs in CFMX related to the
use
Curious question, since CFMX is compiling the source and
such -- is it necessary to scope the 'variables' scope...?
Seems that anything that is created that is outside the
realm of form, url, session, application, server is
automatically shoved into the 'variables' scope/structure.
No,
PROTECTED]]
Sent: Monday, July 29, 2002 5:52 PM
To: CF-Talk
Subject: RE: Scoping variables
Curious question, since CFMX is compiling the source and
such -- is it necessary to scope the 'variables' scope...?
Seems that anything that is created that is outside the
realm of form, url
However, there are currently some bugs in CFMX related to the
use of explicit variables scoping.
Could you provide more details, off the top of your head? I haven't run into
those problems yet (probably due to my own laziness in explicitly scoping
local variables, generally).
Dave Watts,
asked Do you know DOS?
The reply was: No, but I met Tom and Drew a few minutes ago.
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 29, 2002 5:51 PM
To: CF-Talk
Subject: RE: Scoping variables
However, there are currently some bugs in CFMX related
CF automatically will search up if you only use q. If you don't
want that,
then specify URL.Q, or Variables.Q, or whatever. If you _want_ it to
scope
up, just use q.
==
=
Raymond Camden, Principal Spectra Compliance Engineer
by doing exactly what you said!. Prefix your variables with the
scope e.g.
url.q, form.q, client.q, etc
The order with which CF looks for them is:
QUERY RESULT VARS
LOCAL
CGI
FILE
URL
FORM
COOKIE
CLIENT
--
Andrew Ewings
PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 2:45 PM
Subject: RE: Scoping Variable
by doing exactly what you said!. Prefix your variables with the
scope e.g.
url.q, form.q, client.q, etc
The order with which CF looks for them is:
QUERY RESULT VARS
LOCAL
CGI
FILE
wasn't there a switch in cf admin that would only use SCOPE
variables
and WON'T allow, let say: a URL.p to be considered a FORM.p?
I don't believe so.
I think I read it boost performance also? but I might be confused
with
something
else.
Yes, it is better to scope your variables, not
wasn't there a switch in cf admin that would only use SCOPE
variables
and WON'T allow, let say: a URL.p to be considered a FORM.p?
I think I read it boost performance also? but I might be confused
with
something else.
You're probably thinking of Enforce Strict Attribute Validation in
the
1. Can variables in the application scope be made available to custom
tags?
(I know I can set application variables in the request scope which will
make
them available to custom tags.)
Yes Application Scoped vars are available to Custom tags. The application
scope that is used is the scope
63 matches
Mail list logo
