But this is just a developer *convenience*, not really a *best practice*.
Here's a good argument for that method chaining:
<cfif not structKeyExists(application,"foo")>
<cflock name="myApplication_foo" type="exclusive">
<cfif structKeyExists(application,"foo")>
<cfset application.foo = createObject("component","com.acme.foo")
/>
<cfset application.foo.init() />
</cfif>
</cflock>
</cfif>That code is not thread-safe whereas if you chained the methods, it would be:
<cfif not structKeyExists(application,"foo")>
<cflock name="myApplication_foo" type="exclusive">
<cfif structKeyExists(application,"foo")>
<cfset application.foo = createObject("component","com.acme.foo").init() />
</cfif>
</cflock>
</cfif>
Why? Because the code checks for the *existence* of application.foo, not whether application.foo is initialized. By doing create-and-initialization in one expression, you avoid getting into the state where you have a created-but-not-initialized object.
Think this doesn't happen in real code? This was one of the thread-safety fixes that had to be made to Mach II between 1.0.8 and 1.0.9: in 1.0.8 the AppLoader init() method did not return "this" and the initialization code in mach-ii.cfm was not thread-safe because it couldn't chain the methods - 1.0.9 fixed that with a three-line change (change init()'s returntype=, add <cfreturn this /> and chain the init() call onto the createObject() call).
In my book, that makes it a best practice.
Telling me how to return my init() method is not a best practice, it's you dictating how to *design* my CFCs, which shouldn't be the point of a best practices document.
I disagree. Design patterns are precisely that - "dictating" how to design your CFCs and they are best practices (for specified problem situations). When my job was writing coding guidelines for C++ in the early 90's, the biggest part of those coding guidelines - and the aspect that clients wanted more than anything else - was the design guidelines section. It focused on increasing encapsulation and cohesion and reducing coupling (in measurable ways) - it focused on how to design classes. Today, many people are still specifically looking for advice on best practices in designing their classes.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
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]
