- 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
- Immature, and full of niggly bugs!
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.
Also related to this topic is the CFPROPERTY
Any variable within a CFC that is not explicitly declared with the CFPROPERTY
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
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.
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 ;)