So you are suggesting that we should create best practices for every example of where an application was poorly coded? No, then why this particular example? Isn't this a situation where the lack of constructors is causing problems and you are creating a best practice as one particular workaround?
Not really - even in BlueDragon's implementation with <cfconstructor> you still need to call init() if you want to pass in constructor arguments, just as you do with Java, and therefore I will argue the best practice recommendation is still - in CFMX, in BD and when using Java objects - to chain the init() call onto the createObject() call.
The chaining recommendation is not about how init() is implemented per se but about writing code in a style that ensures you can't get uninitialized objects lying around.
The "lack" is not being able to specify initialization arguments in the createObject() call like this:
<cfset obj = createObject("component","foo",arg1,arg2,arg3) />
If that were possible, *that* would be best practice (regardless of whether the underlying mechanism was an init() function or a <cfconstructor> or even a Java object).
Instead, we have to do this:
<cfset obj = createObject("component","foo").init(arg1,arg2,arg3) />
whether we're using CFMX or BD (or constructing a Java object).
Wouldn't it be better to advocate in this case thread safety as a best practice? Does that achieve the same goal without polluting the practice with a stylistic concern.
Thread safety is a separate issue - and obviously very important. For the most part, thread safety is really about making sure you use 'var' to declare variables in methods instead of letting variables accidentally fall into the unnamed scope (which is equivalent to "variables" scope). Yes, locking is also part of thread safety but it is a smaller concern, IMO, because it typically only affects initialization code...
Regards, Sean
----------------------------------------------------------
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]
