you can cfinclude outside of a cffunction without endangering threadsafety (in this case we are just injecting common functions into the cfc, coldfusion "includes" them as the cfc is instantiated). The effect of using cfinclude WITHIN a cffunction is much different, causing any local function variables to be automatically copied into the variables scope, basically the "instance" scope of the CFC.
-dave >>> [EMAIL PROTECTED] 5/10/2004 4:51:37 PM >>> I think this is an excellent idea. Obviously, based on the no cfinclude rule, this means not including the cfFuncitonWrappers and utilityFunctions in .cfcs, correct? This is kind of what I was driving at with my earlier "FarCry's Future" thread. Based on Geoff's response, I now know that a lot of the component development in FarCry was done before many of these "best-practices" came to light. Some these emerging "best-practices" are only recommendations related to coding style, i.e. always use init for the constructor method, but others, such as this cfinclude issue, do have serious consequences. Even the FarCry FAQs say, "FourQ probably now needs an overhaul in light of best practices emerging in CFC development." In addition to the two rules you mention below, I'd be interested in coming up with a list of best-practices or coding standards to be followed in the core. This may be asking to much, as I know this is an open source project and everyone has there own coding styles and ideas of how to best code CFCs, but I'd like to throw the idea out there... Best, --Nathan >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf >Of David Ross >Sent: Monday, May 10, 2004 3:57 PM >To: FarCry Developers >Subject: [farcry-dev] thread safety/cfinclude > >I thought I would bring this up here since Farcry makes a lot >of use of cfincludes within cffunctions. > >Some people have discovered a bug/problem with using cfcs and >cfinclude in that using cfinclude effectively eliminates any >chance of making a cffunction thread-safe. >http://www.camdenfamily.com/morpheus/blog/index.cfm?mode=entry&; entry=60EE263F-C9FD-43B5-ED1FD4C7B0343055 > >For instance, in tree.cfc (which is application-scoped so it >is vulnerable to thread-safety issues), many of the function's >bodies are cfincluded. Technically, it is feasable that one >cffunction inovacation would receive another's result. Now, I >know most of the work that farcry does is not exposed under >heavy load due to caching, however I'm wondering if a lot of >the persistant CFCs should be updated to "best-practice" in >terms of thread safety, which means: > >-no cfinclude >-var EVERYTHING, even names of cfqueries and iterators > >thoughts? > >-dave > > > >--- >You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] >To unsubscribe send a blank email to >[EMAIL PROTECTED] > >MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia >http://www.mxdu.com/ + 24-25 February, 2004 > > --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
