CFUNITED 2007 Website
 Receive our newsletter   about | contact us | home  
Interview Page

"Heresy! Embracing Duck Typing in CFCs " interview with Hal Helms ***************************************************

Michael Smith: This time we are talking with Hal Helms about his CFUNITED-06 talk "Heresy! Embracing Duck Typing in CFCs". So why should a developer come to your session Hal?

Hal Helms: Maybe for the chance to burn a heretic at the stake?

Michael Smith: BYOM: Bring Your Own Matches...

Hal Helms: Seriously, I think that over the last two years, especially, ColdFusion developers have been embracing object orientation. We've seen the introduction of OO frameworks such as Mach-II, Model Glue, ColdSpring, etc.

Michael Smith: Yes, it's clear that some substantial "sea change" is underway.

Hal Helms: And that's the problem.

Michael Smith: The problem is that ColdFusion developers are embracing OO? But you're the one who's been preaching this for the last five years!

Hal Helms: No, the problem is that the conventional OO wisdom will lead ColdFusion developers, especially those new to OO, into frustration and failure.

Michael Smith: Why is that?

Hal Helms: Because the conventional OO wisdom is to treat ColdFusion as "Java Lite". And this is nowhere more evident than in the advice given to CFers to provide returntypes for their methods and argument types for methods.

Michael Smith: And you're against that practice?

Hal Helms: It's not just the practice I'm against; it's the misunderstanding of the enormously different roles types play in Java and ColdFusion that's so damaging. So many ColdFusion programmers are being encouraged to believe that they're doing the right thing by specifying data types.

Michael Smith: But surely that's a good thing? Isn't it important to know whether you're going to get a number or a boolean as an argument to a method?

Hal Helms:If we were dealing only (or even mainly) with simple data type, that would be fine. But we're dealing with user-defined data types -- classes, in other words. And that changes things.

Michael Smith: How about an example?

Hal Helms: If I have a method that accepts, as an argument, an Educator -- maybe it's a "register" method in a EducatorConference class -- can I send the method a Teacher?

Michael Smith: Assuming that Teacher is a subclass of Educator, yes, you can.

Hal Helms: Because Java -- whoops, I mean ColdFusion -- will "type promote" the Teacher object to an Educator object, right?

Michael Smith: Right.

Hal Helms: OK. And would you allow me another method -- "enroll", possibly in a UniversityRegistrar class that accepts arguments of type, Student?

Michael Smith: Why do I feel like I'm being led like a lamb to the slaughter... OK, I'll grant you that method.

Hal Helms: Great. I happen to have a StudentTeacher class. I'd like to send an object of that class to UniversityRegistrar's "enroll" method. Any problem?

Michael Smith: Not so long as StudentTeacher extends Student.

Hal Helms: Oh, right. Because Java -- whoops, I mean ColdFusion -- will "type promote" the StudentTeacher object to a Student object, right?

Michael Smith: Uh oh...

Hal Helms: Yes, you see where this is leading. Shouldn't I also be able to send our StudentTeacher to the EducatorConference's "register" method. After all, the StudentTeacher is every bit as much a Teacher as it is a Student.

Michael Smith: It's the classic single/multiple inheritance problem.

Hal Helms: It is, indeed. Through doing the right thing -- typing our argument types, in this case -- we've gotten into an impossible mess.

Michael Smith: But languages like C# and Java manage it somehow.

Hal Helms: They do so through a construct called an "interface" that provides for multiple type inheritance without the sticky issue of code inheritance.

Michael Smith: So, you're going to argue that Adobe should add interfaces to ColdFusion?

Hal Helms: No! What good would that do us developers in the trenches who face these problems right now? Besides, that's exactly the wrong solution. The reason that C# and Java need interfaces is that they are statically typed -- that is, data types get determined prior to run time. But ColdFusion doesn't suffer from this restriction: it's dynamically typed. What we need is to embrace the fact that ColdFusion *is* dynamically typed. And we haven't even started to talk about mixins! There are all kinds of new possibilities!

Michael Smith: This certainly does fly in the face of conventional wisdom about OO in CFCs.

Hal Helms: That's why the title of the preso begins with "Heresy!"

Michael Smith: Well, I'll be sure to be there for your session. After all, someone needs to be there to dowse the flames…