CFObjective Session Summaries Continued: Duck Typing
Posted on Mar 14, 2006
For additional summaries please refer to yesterday's post. Oh, and just a reminder, these are summaries and represent the opinion of the presenter (unless I note otherwise) - just wanted to get this out of the way since some might take issue with portions of Hal's presentation.Hal Helms on (Heresy!) Duck Typing
Hal began by arguing against the common statement that "ColdFusion is Java" or the common attempt to represent ColdFusion as "Java Lite". He believes that by limiting ourselves to this model, we overlook some of the power of ColdFusion because we try to add rules that are not relevant to the language (for example: type safety). Compiled languages need type safety and ColdFusion is not a compiled language. ColdFusion follows a "Dynamic Type Model", which until recently the conventional wisdom had been that only statically typed languages were robust/secure enough for enterprise application development. The growing popularity of Ruby has begun to change this perception.
With regards to trying to fit ColdFusion into a static-typing model, Hal discussed the "problem" of the lack of null. In Java, null fulfills the "contract" of any data type. This can still lead to error like the dreaded "null pointer exception" when a method is called on something that has null as its instance value. So, even having null is not a foolproof solution.
CF, like Java, has a single inheritance model. To solve the issues this creates (Hal used the example of the StudentTeacher), Java uses interfaces, which are type specifications with no implementation. There had been much discussion about the addition of interfaces during the conference, particularly because Tom Jordahl's keynote had stated that this is likely to be a new feature in the next version of CF (this met with applause from a number of attendees). However, Hal feels that this will add no value to the language at all (while once he felt differently). Since there is no compiler in CF, there is no way to enforce type safety even when interfaces are added. Plus, interfaces violate the DRY principle: as in "Don't Repeat Yourself".
The use of mixins can solve the StudentTeacher problem without the need for interfaces. For example, a student can be given a "battlefield promotion" by using a dynamic, object-based mixin of the teacher methods (Hal had some example code that he used to show this method using a baseComponent which all components extend...or editing the built in baseComponent in CF). Another example would be to use cfinclude in your components to include the teacher and the student methods into a StudentTeacher class, thus solving the problem without violating DRY. Hal also showed how using the baseComponent, you can create universal getter and setter methods that you can override on an as needed basis (see Hal's site for more details or code examples. Sean also pointed out in a comment that, prior to most of our expectation, you can actually cfinclude another component (even with cfcomponent tags); the include does not need to be a cfm file.
All of these problem solving techniques, it was Hal's assertion, only became available when you let go of ColdFusion as Java Lite and the perception that static-typing is either better or necessary, and when you embrace ColdFusion's dynamic typing as a benefit rather than a hindrance.
I have more presentation summaries to come, but since this one was a bit long, I will save them for tomorrow :)
Comments
There are currently no comments for this entry...be the first!