Vince argues that the current implementation of CFCs is a halfway house and that BlueDragon is just trying to "fix" the implementation by making ColdFusion more Java-like. I've already said it's an approach I don't think is appropriate because I think it just makes ColdFusion harder to learn and harder to use - if people want this stuff, they might just as well drop into Java and use that directly (since Java objects can be used so easily in ColdFusion).

To answer Vince's two questions tho'...

Do I think ColdFusion is already "Java Lite"? No, I don't. But it's dangerously close and the introduction of interfaces and abstract classes and so on definitely tips it over the edge into that territory. We are limiting ourselves as ColdFusion developers if we follow Java's lead too closely. There are other OO languages out there that have a lot to offer us in terms of concepts and, potentially, new language features for ColdFusion. There's a lot of buzz around Ruby and then there's the grandaddy of OO languages, Smalltalk. Both strong OO languages, both are dynamic languages - like ColdFusion - and Ruby in particular is appealing to Java developers because they can lose the shackles of their statically typed, compiled language and build things faster. A lesson that should not be wasted on us CFers!

Do I think the current implementation of CFCs was a mistake in the first place? No, absolutely not. They provide a reasonable OO framework combined with the power of a dynamic language. The ability to modify objects on-the-fly has enabled a number of frameworks and utilities to appear that serve our community very well. If I could go back and provide more input and direction for the initial implementation of CFCs, there are a few things I'd do differently but only in terms of how things are named (choosing this as the name of the public data member scope has caused a lot of confusion, choosing private for an access mode that is more like protected in other OO languages has also caused confusion).

If you want to write Java-like code, ColdFusion is a very verbose way of doing it. If you want to write Ruby-like code (or Smalltalk-like code), ColdFusion is a very good fit. Java is not the holy grail.

(And: "Java is not the holy grail" I couldn't agree more)

Is there ROI in morphing the CFC to work like a JAVA classs, probably not, infact there has been alot of discussion around the fact that most CF developers are not hard core OO Architects. I think it makes alot more sense to find out what the community at large is looking for from the CFC and tailor it to those needs, isn't that the point of a dynaamic language anyhow? If ColdFusion can sit on an enterprise ready infrastructure, giving me the capability to leverage high level concepts, and quickly deliver incredible apps, then I am ahead of the game. I have always said that ColdFusion allows me to stand on the shoulders of Giants, thus making me look like a giant to my corporation.

By the way I have developed some pretty high scale OO applications in both .Net and Java. OO and Java are not synonymous and there are alot of powerful, unique OO concepts in a multitude of different OO languages, to force the CFC to be the same as a Java class seems short sited to me.....

I'm not sure I understand why you think adding interfaces, etc. would make CF "harder" in any way since those features would be entirely optional to use. I could definitely buy that it's easier for people who don't know what they are doing to get themselves in trouble with such tools around, but that has been an issue with CF from the very beginning -- and is the primary reason that CF has such a bad reputation in most developer communities. It is the addition of the various tools such as CFCs (and eventually interfaces, etc.) that continue to win over more advanced developers because while it's great to have a low barrier to adoption for people with limited programming experience, CF has benefited from ratcheting up the "high end" so that advanced developers don't run into a ceiling of possibilities.

1. Books about the language and the language documentation itself must get thicker and thicker to describe all the possible features. That is intimidating and leads to a steeper learning curve (because it's harder to figure out what is essential to learn and what really is "advanced" and not essential... besides, a lot of people try to learn the "advanced" stuff anyway because they don't like to be told "Oh, don't worry your head about that stuff over there... it's complicated and you're a newbie so stick to this stuff here!").

2. If the language feature is there, it will be used by some number of people. That makes it harder for newbies to pick up other people's code and maintain it. Again, a steeper learning curve.

Well, there's a third issue: more features = more code in the product = more potential bugs = more confusion and frustration for users (and a steeper learning curve when feature X doesn't behave as they expect - is it a bug or their misunderstanding of the feature).

For example, if you want every instance of a class to have access to a particular setting:

1. Create a factory CFC with that setting as an instance variable

2. Create a single instance of the factory and initialise it with the setting value you want

3. Use that factory to create every instance of the class (needs discipline - obviously it remains possible to create an instance directly without reference to the factory) and either: a) pass the setting on to the instance or b) give the instance a reference to the factory so it can get the setting from the factory whenever it needs it.

As opposed to: 1. Create a class variable 2. Use it

Jaime