Next Steps for CFMX

Having been using CFCs for a while now, it's pretty clear that they're:

• An excellent way to increase code reuse and maintainability
• A good way to allow developers to code in a KIND-OF object orientated manner
• A great leap forward for CF in general
• A sign that CF is maturing into a "proper", "serious" programming language, rather than just a scripting language

BUT, as with any great leap forward, the CFC mechanism is also -

• Immature, and full of niggly bugs!

From my own (highly-biased) point of view, there's a few improvements that could be made which could really raise the bar for CF, and boost it into the "grown-up" strata currently occupied by languages such as Java:

1) Proper variable scoping in CFCs
The current situation regarding CFC variable scopes has been the subject of much confusion and heated debate (For a good summary, see http://cfguru.daemon.com.au/archives/2002_08.html)

I believe that in order for CF to move forward, there should be a clear-up of the scopes, making it more explicit what is public and private. There is already a prefix ( "var", e.g. ) to make variables explicitly local to a method, so how about tidying this up a bit?

Also related to this topic is the CFPROPERTY tag: this tag serves only to define meta-data for exposure through web-services. It seems to me that strengthening this tag would be an ideal way to tackle the scoping issue.

Suggested rules:

Any variable within a CFC that is not explicitly declared with the CFPROPERTY tag should be local by default.
This would mean that it goes out-of-scope and is destroyed at the end of the function within which it is created.

Add an "access" attribute to the CFPROPERTY tag that would function the same way as the "access" attribute in the CFFUNCTION tag
Allowed values would be public, private, and package.
Any instance properties of the CFC could then be explicitly declared as public/private/package, without all the confusing, fiddly variables. / this. palaver.

(note for americans - "palaver" is a yorkshire term, meaning an unnecessary fuss - a Yorkshire version of Much Ado About Nothing might be called A Right Palaver Over Nowt!)

The "this." scope should only refer to properties of the CFC
An upshot of this would be that any attempt to add a this. scoped variable which is not defined as a cfproperty would throw an error.


2) Proper Inheritance and Polymorphism
The inheritance mechanism in MX as it stands is, well.... kind-of OK, but not complete. It has a couple of oddities, most of which are related to the variable scoping issue above.

For instance, you can't call methods on a parent CFC from the child CFC with named arguments, or an argumentCollection. You must pass unnamed arguments in the order they are defined.
( see Martin Laine's post on Issues With Calling Super Method - many people have been through this ordeal! )


This makes what would have been a nice elegant parent/child "is a" relationship into an ugly kludge - for instance, in the init method, you can't pass on the arguments collection from the child to the parent. You have to pass unnamed, ordered arguments instead. This means that the child class has to "know" about the composition of the parent class, which spoils maintainablity, and just feels ... "icky". Every time you add a new property to the parent class, you have to explicitly add it into the child class aswell. Ugh.


Of course, the trouble with tightening up the variable scoping is that, unless it's thought out VERY carefully, it could break compatibility with existing code, which may well be why it hasn't been done yet. I'll leave that as a problem for those MM developers with access to the source code ;)