At CFUnited 2006 there was a lot of talk of DuckTyping* and when I finally got it, I adopted it somewhat (only to a level) for some simplicity's sake when writing my own code.

I was just reading a blog post by Michael Dinowitz and its got me thinking that this type of coding is going to REALLY annoy me when I implement CFC introspection in CFEclipse.

Lets look at some code and I can explain better, here is a simple basic component:

In CFEclipse, when we call this we can do it like so: <cfset myObj = CreateObject("component", "SimpleComponent")>

We now have myObj set to be a SimpleComponent, great, we can look that up, but what happens if we have two components called SimpleComponent in our project? ColdFusion can deal with this (as it would expect the SimpleComponent to be in the "/" mapping setup in the administrator, the web root, or in the same folder as the calling code.) but CFEclipse can only do two of those, as it wouldn't know about the ColdFusion mapping.

So, lets add another attribute to the component tag (ColdFusion wont mind, I promise!): And now we call our CFC as follows:

Great! Now CFEclipse can do a quick scan through all the components looking for the alias! We have set the myObj variable to map to the SimpleComponent.cfc file. Introspection can happen now! We can list the functions in that component. But what happens (like in a lot of components) if we were to call the constructor? <cfset myObj = CreateObject("component", "com.coldusing.cfc.SimpleComponent").init()>

Now CFEclipse is lost. This is a runtime call, and now, as far as CFEclipse is concerned, myObj is of type "any" so it doesn't know what Component it is... no more introspection for you.

There are a couple of ways I am thinking that we could get over this problem, and Michael mentioned one way: to add information to the hint attribute:

This would mean that if there is no returntype, or returntype is "any", we have a look in the hint attribute and use that. The downside is that a lot of people have already written things in their hint attribute, such as documentation and what not. Let's come up with something else.

The other way we could do this is to add another attribute, _returntype, ColdFusion would ignore it, but it would be visible to CFEclipse:

Now, that sounds like something we could do, and even configure CFEclipse for (such as a setting which says, look for returntype in returntype, hint then _returntype)

You can imagine the same thing happening for arguments, so that when you type: <cfset myObject.getSomething(...)>

at the point when your cursor is in the "..." it would show you the variables and types (something like var1:String). (I can do another blog post about this if people like, but its the same idea)

What does the community think about this? On one hand its a bit against the ethos of CFEclipse, since it will be adding to your code, but on the other, you gotta give me a hand here! There must be a nice way of doing this! (for your info, I prefer the additional attributes since its kinda part of the language)

• DuckTyping in essence is setting the returntype to "any" or "void" in CFC cffunctions and the type to "any" in cfarguments to speed up the code as there is no need for validation of the object types that are being passed into and out of a function. It also means that the returned objects can be treated the same way even if they are not the same type of object.