I would rather use a specific Init() method rather than rely on a behavior of the CFC. I previously used the psuedo-constructor area, but with an uneasy feeling that MACR may change it and, in turn, break my code.
Backward compatibility is very important to the CF product team so I doubt they would outright break it but I can imagine the pseudo-constructor approach being deprecated if a 'real' constructor was added to CF (deprecated = marked for *possible* future obsolescence).
By specifying Init(), MACR is less-likely to break my code w/o affecting all other users as well.
The more common an idiom it becomes, the less likely it is to be broken... It's good to see New Atlanta recognize this idiom as well and implement their <cfconstructor> tag in a way that still maintains code using init() (and allows init() methods to be migrated to <cfconstructor> without changing code that uses the components).
A compromise would be to coding an Init() method, but also invoking that method in the psuedo-constructor area...
<cfcomponent>
<cfset init()>
<cffunction name="init">
... code goes here ...
</cffunction>
</cfcomponent>
Note that BlueDragon didn't support called a function that wasn't yet declared in one of their betas and it wasn't clear they'd support it in the final release. You'd need to move the call to init() *after* the definition of init() for BD in that case.
However, I don't like this solution very well. What if I want to call the init() method and specify other arguments? That means the init() method fires once on instantiation and then again when I call it programmatically. :-(
Agreed. Hence using createObject().init() is a good practice to get into (since it works for both Java and CF objects - and it works in CFMX and BD).
Sean A Corfield -- http://www.corfield.org/blog/
"I have always wished that my computer would be as easy to use as my telephone. My wish has come true - I no longer know how to use my telephone."
-- Bjarne Stroustrup
---------------------------------------------------------- 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]
