http://rickyclarkson.blogspot.com/2006/07/duck-typing-in-java-and-no-reflection.html

I’m suprised how many people say that they frown on duck typing because of a Java background – introspection is a key component in Java – for instance, when pulling something off of a Vector you commonly have to find its type to work with it. If the object isn’t the type you want to work with you keep searching through the Vector – very common technique.

Is such a thing useful? Let’s see. If I have an array of objects and wish to remove a specific object from the array, how can I do this? I can’t loop over the array, asking if the object I want to remove EQ the current object in the loop. CF will error out if I try this.

Although some people never find themselves in this situation according to their blogs, I find myself very often in such a situation. To me, the idea of object identity should be baked into every instance, so my base Object class has a unique ID created when the object is instantiated. I then create an equalTo method in Object.cfc that accepts a CFC and checks to see if it’s ID matches the argument’s ID. All CFCs that would normally not extend a CFC then extend Object.cfc (which I place in the CustomTags directory).

This is certainly not an orginal idea of mine. Picasso once said that good artists borrow, but great artists steal. Let’s just say I “liberated” the idea from Java.

Since I advocate duck typing (and am therefore not concerned with the type of an argument or a returntype), I also created universal “get” and “set” methods that receive an argument (x) and check to see if an actual getX or setX method exists. If it does, the universal get or set calls the specific getX or setX method. If no specific getX or setX method exists, the universal get or set references an instance variable, x.

These seem to me good examples of the usefulness of a universal base class. I’ve certainly seen the idea of a universal base class abused, with people placing things like persistence in the base class (truly a kitchen sink approach), but that is something I would discourage.

I started a repsonse and found it to be a little long so I posted an entry:

http://cfrant.blogspot.com/2006/07/one-last-piece-on-duck-typing-then-i.html

Agreed. However, using your example, I’d argue that the “specialty projects” are the equivalent of an “advanced technique” in ColdFusion. That was the point I was trying to make; don’t blindly remove typing because the other voices in the community have advocated it. Further, I did not mean to imply that frameworks were the *only* place to use duck typing. Rather, I submitted that, to date, in all the ColdFusion code samples I’ve seen posted, the framework-related code posted by both Joe and Sean on their blogs have been the most pragmatic uses. I certainly have seen the “hello world” examples of duck typing, but nobody has posted “real world” code that shows why they used duck typing to solve a particular problem…even your Plane/Car example is merely a learning example, not actually implemented.

Great discussion.

You make some valid points.

I see duck typing as a tool in our development toolbox. For example, a construction worker could build a house with only a hammer, some nails, and some type of saw. And people have done that just fine for many, many years. However, most homebuilders now have huge trailers filled with hundreds of tools that they take with them on job sites. Many of those tools are considered ’specialty’ tools and only get used a couple times a year. Of course, some builders work only ’specialty’ projects and use them more often but everyone uses them sometime or another.

The point is these ’specialty’ type tools are not necessarily *needed*, we’ve been developing just fine for a long time without them (this wasn’t even an issue in CF5 and earlier). However, we would be hindering ourselves by not using these new tools to provide more effecient and elegant solutions. I don’t think we should apply a liberal brush and take typing information out entirely, but to say that only frameworks could use this solution is equally as wrong in my point of view (unless you are working on trivial projects).

“As for documentation, anyone who isn’t use hint= on every cfcomponent, cffunction and cfargument needs to be lined up against the wall…”

Sorry, but with proper typing (there it is again), coding (the one function for one thing) and naming of your functions and arguments (using “x” as a variable name isn’t good practice), you don’t need be wasting your time with putting hints onto every component, function and argument.