I prefer to create libraries of functions as CFCs - for example I've got a "paths" CFC that contains 10 or so functions related to system/relative/application paths.
An instance of that paths CFC then becomes a property of my Application CFC. However the line is thin: as a functions container a CFC is no more complex than a structure. You could also create a "Paths" struct and store your functions in that struct. 1) In both cases, CFC or Struct, you'd still be able to call "Paths.getRelativeToRoot()" Neither makes for a shorter or cleaner call - they're both exactly the same (there's no way to determine the container used from the call). 2) In both cases you'd be able to persist the entire thing into any of the memory-resident scopes (Server, Applicaton or Session). 3) Both are limited by CFs inability to serialize functions to WDDX. 4) In many important ways CFCs are structs in CF (you can do an IsStruct() and get "true" for example). There is definitely a small amount of overhead for a CFC compared to a Struct (a very small amount), but only on instantiation - after that I can't see ANY performance difference between a struct and a CFC used like this. A struct has the potential benefit of being compatible (if the functions within it are) with CF 5.x. A CFC has some abstraction benefits (which is the main reason I like them for this). For example in a CFC I've also got access to the THIS and VARIABLES scope. My Paths CFC, to continue the example, takes an instantiation parameter which (when called from the application.cfm) sets a public variable as "this.AppRoot". If that variable exists some functions in the CFC can generate paths to the appRoot as well as to the webRoot (useful for when your application isn't at the root of the web server). To do the same thing with a struct I'd need to store the value either as a key in the struct or in another location. The latter solution decouples the function from the information needed to run it (bad in my opinion) and the former requires that the functions know where the struct will be stored. In other words a struct has no "self" reference so in a function I'd have to know that this value would be in "application.Paths.AppRoot". I couldn't, then, move the struct around as I see fit. A CFC method just has to know "this.AppRoot" no matter where that CFC has been placed. This is also a huge issue for function libraries that self-reference (have functions that call other functions in the library). This also leads to the possibility of using different sets of specially "primed" functions. My CFC Paths functions use AppRoot, but I could have multiple instances of this CFC using different roots if I wanted: an "ImagePaths" instance, an "AdminPaths" instace or any number of applications. None of the functions would have to change at all. CFCs allow you to change the container of the functions without changing the functions. Even if you don't need to do that now the freedom to do it is nice. All that being said I still use "plain" UDFs sometimes. If a function is used in only place I will add that function inline in the template. For example my "displayBreadcrumbs()" function is only called in my Wrapper custom tag so it's right in there. (And yes, I still think Custom Tags are the best tools for a lot of jobs.) In the end I'll say that if you're setting up the same functions for every request (by CFINCLUDING or creating the CFC in the application.cfm every request) then you're wasting cycles. It's not much of a waste, but storing common functions in a persistent scope will eliminate that small loss. If you are doing this however then CFCs are definitely (very slightly) slower - but it's nothing you'd ever notice. Once you're talking about storing functions persistently (in the Server, Application or Session scopes) then I'm sure there is no real difference between using a CFC or a struct as the container for them. In that case the freedom CFCs provide in determining the final storage location without requiring code changes win out in my opinion. Jim Davis ---------------------------------------------------------- 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]
