The very fact that CFCs went through a lot of implementation iterations shows just how slapped together they were.
Are you saying that you don't go through design and implementation iterations when building software? That would make you very unusual in the software world... ;)
There are plenty of examples where design flaws became features e.g. the pseudo-constructor area or worse, the output attribute.
I agree that the pseudo-constructor idea was less than ideal but most folks seem to be standardizing on init() as a constructor and only using the pseudo-constructor for bare bones default value initialization (like other languages allow initial values to be specified for instance variables). Hopefully we'll get a fully-fledged constructor notation in a forthcoming version of CFMX.
I'm not quite sure what you objection to the output attribute is - could you elaborate?
Why anyone would think it would be a good idea to apply tri-state logic against a boolean attribute I don't know.
???
I can't imagine how an OO person would be very happy with CFCs considering how shallow the OO capabilities of CFCs are.
Well, just because you can't imagine it doesn't make it less true :)
I would like to see: a) interfaces / implements b) an integrated constructor notation c) null
I can live without the second item since I have adopted a style that works much the same as 'real' constructors: createObject().init()
The first one is harder to live without in an OO world (but it is possible to live without it).
The third item isn't really specific to OO but the absence of null can make certain patterns harder to implement elegantly.
So, yeah, even as an OO language diehard (eight years on the C++ standards committee and doing hardcore C++ development, nearly seven years of Java development), I find CFMX pretty good for OO development.
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 word '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]
