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 record, Ray said MX in one of the comments to the first blog post I referenced, but he was guessing because he couldn't remember).
As to refactoring along these lines, I guess that really depends on the application. Many applications are relatively small, and serving a single domain. It may not be necessary to put out the effort, in those cases. My original thoughts on this topic came from years of working on a large codebase that concurrently ran 2,000 sites. Unscoped variables were all through, when I got my hands on it, and in the process of scoping (necessary to eliminate bugs, shave off unnecessary scopeCheck, and clarify purpose) we discovered memory leaks in the application. Research, at the time, uncovered several postings around the net on the use of the Variables scope and issues with Garbage Collection, something we were seeing in JVM profiling as well. This was when I started working on this theory and putting it into practice, and we did see a significant performance gain (30%). Apparently I wasn't completely alone. I've found several other developers, at different conferences in discussions, who came to the same conclusions as well. 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 a habit now, and one that works well for me (and my variables are always scoped). It also makes sense to me, where naming (of the other scopes) serves some purpose in defining where a particular variable might've be declared. But that's me. Last note, I did forget caching. For many/most/all apps, some form of caching would be critical. Variable scoping, DB performance (queries on up), JVM tuning, and caching. Steve 'Cutter' Blades Adobe Community Professional Adobe Certified Expert Advanced Macromedia ColdFusion MX 7 Developer ____________ http://blog.cutterscrossing.com 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 "The best way to predict the future is to help create it" On 5/19/2011 5:28 PM, Dave Watts wrote: >> 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 it's port to Java, or even the thought of OO web >> application development, I think that many of the scopes kind of came >> about as an afterthought. Containers, of sorts, to fill specific needs. >> The Variables scope always existed, it just didn't get the "VARIABLES." >> prefix until MX (if I remember Ray). > I'm pretty sure that the name "Variables" predates MX by at least two > versions. The Request scope was introduced in 4.x, primarily for > Spectra if I recall correctly - Spectra had a lot of custom tags, and > passing variables back and forth from custom tags to their callers is > a bit of a pain. I wouldn't be surprised if "Variables" has always > been available as a named scope, and I'm pretty confident it was in CF > 3 (which introduced CFML custom tags) - I remember it being in the > official Allaire course curriculum. And i don't really think that the > Variables scope itself is an afterthought - it's the default scope, > and for a long time it really didn't need a name to separate it from > the non-default scopes. > >> *The following is deduction, conjecture, and opinion. Discuss freely if >> you wish, this is just how I see it.* >> I think that usage of the Variables scope, on a high level, was never >> well documented. That years and years of examples and sample >> applications were written without really thinking about what the correct >> usage of the scope might be. The Request scope, by it's name, appears to >> be where you would place variables to be used throughout a request. The >> Variables scope operates very similarly, until you declare them inside a >> custom tag. A custom tag can directly access a Request scope variable, >> but Variables declared outside that tag are invisible (without using the >> CALLER scope). From a timeline perspective, this is important, because >> custom tags predate cfc's, which have the same constraints. > It's very simple - I don't think a lot of conjecture is needed. By > default, when you create a variable within a page, it's only available > within that page. Before CFML custom tags existed, this wasn't a > problem, as there wasn't anywhere else you had to worry about; when > you CFINCLUDE one page within another, for all practical purposes you > end up with one single page at runtime. But custom tags execute > separately from your page - your page halts when the custom tag runs, > and restarts when the custom tag has finished running. > > And CFML has been consistent about this behavior, really. CFCs are > separate programs, just like custom tags, so they have their own > separate local variables that are referenced using the "Variables" > scope. Functions, on the other hand, are not separate programs, > they're embedded within your page (either literally, or via CFINCLUDE) > so they share the same Variables scope - and need their own specific > function-local scope. > >> My theory is that Variables were to be used within custom tags only. The >> problem being, custom tags were just .cfm templates with no way of >> explicitly declaring them as custom tags (outside of how they were >> called), and as such any .cfm page could 'do' Variables. > I don't think that theory is borne out by history. > >> As I put in the second item above, I think the use of the Variables >> scope, outside of it's encapsulated usage within a custom tag or a cfc, >> is a mistake. I think it was something that ultimately shouldn't have >> been possible, and once it was discovered as an issue it was too late to >> change behavior because of the thousands of applications that would have >> needed to be refactored. > Ugh. No. > > In general, in any programming language, you want to use the most > restrictive scope possible. If you're only going to use a variable > within a single page, and not within any custom tags, there's no > reason not to use the Variables scope. There's no reason to refactor > applications that are doing this. If you're going to use a variable > within a page, and you also want that variable to be available to > custom tags, then sure, use the Request scope. The key lesson isn't to > use Request instead of Variables, it's to know the difference between > the two and use each appropriately. > >> I can say this: poor performing CF apps can generally be greatly improved by >> scoping all variables, paying heavy >> attention to the db (queries, indexes, execution plans, etc), and tuning the >> JVM for the application in use. > In my experience, the performance improvement you get from scoping > variables that are currently unscoped is not usually worth the time to > change the application. If you've done things the right way from the > beginning, great - but I've yet to see the application where (a) this > hasn't already been done, while at the same time (b) the database on > the other hand has been perfectly tuned. Also, you left out caching - > the single biggest performance enhancement in my opinion. Out of those > four items, scoping is almost insignificant. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > http://training.figleaf.com/ > > Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on > GSA Schedule, and provides the highest caliber vendor-authorized > instruction at our training centers, online, or onsite. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:344734 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
