Your CFLOCK eliminates the difference between the two examples. That only matters if you're not CFLOCKing the access to the shared scope var (which is reasonable, as long as the var is stand-alone).
So the benefit is really that if you make the createObject() and init() calls one line (meaning one LValue), then you don't have to lock the initialization, because it's one operation, right? This is the first reasonably compelling argument for putting createObject() and init() together, so I want to make sure I understand right. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield > Sent: Tuesday, March 16, 2004 1:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Returing "THIS" from init(), WAS: RFC, > CFC Best Practices > > On Mar 16, 2004, at 12:32 PM, Dave Carabetta wrote: > > 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] > ---------------------------------------------------------- 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]
