- Duck Typing on Wikipedia
- Judith Dinowitz's Vy a Duck? article in Fusion Authority
- Hal Helms' Toward a New Orthodoxy article in CFDJ about duck typing
- Brian Rinaldi's review of Hal's cf.Objective() presentation about duck typing
- Helms and Peters "Out Loud" podcast episode 11 (MP3) and episode 12 (MP3), which cover duck typing in two parts
- The duck typing definition on ooGlossary.com by Jared Rypka-Hauer
- Hal's CF Live! presentation on duck typing (this is a condensed version of the talk he gave to both the Atlanta CFUG in February and again at cf.Objective() - and that he would have given at CFUNITED)
More on Duck Typing
July 3, 2006 · 7 Comments
With the confusion about duck typing and the misguided focus on performance, I thought I'd post some third-party references that folks can (and should) read:
Tags: coldfusion
7 responses so far ↓
1 Adam Cameron // Jul 3, 2006 at 11:31 PM
There's been some figures posted showing what sort of gains CAN be had, which seemed pretty good, and a tangible reason to consider this avenue.
A lot of bods won't actually care about the other side of it.
To me it comes across as slightly interesting, but smacks a bit of "this month's fad is to pretend we're RoR programmers; pretending we're Java programmers is *sooo* last month".
Sure, having more options in the arsenal is always a good thing, and could be spun as showing how flexible CF is. But what's WRONG with leveraging this concept to get more out of CF, performance-wise?
--
Adam
2 Ruud Hermans // Jul 4, 2006 at 12:19 AM
Two things should be seperated here: duck typing and the speedhack as a side-effect of duck typing.
The latter hasn't got anything to do with duck typing, apart from it being a side-effect. Due to the nature of ColdFusion, NOT due to duck typing!
The danger with leveraging this side-effect is that people are going to use it by default. And that is a bad thing for these (and probably more) reasons:
- it is a typical form of premature optimization, which is known to be the root of all evil.
- not defining types and stuff anymore means you're going to have to do without that additional layer of valuable documentation.
- debugging becomes more difficult because of less detailed error messages as a result of undefined types.
Having said that, of course, if you have a performance bottleneck somewhere, there's no law against using this speedhack. But do consider other alternatives (design-flaws?), for they are likely to exist.
Regards,
Ruud
3 Adam Cameron // Jul 4, 2006 at 1:17 AM
I agree fully, and never you mind, I'm not *personally* about to leap out and remove all my typing and requiredness from my CFCs, "just because". I'll cross that bridge when/if I need it. Indeed you've hit the nail squarely when you point out that there's plenty of other better places to seek performance increase than this sort of thing.
The thing I find more interesting about this recent flurry of attention duck typing is getting (it itself is not interesting at all, in my view, but hey), is that CF performs these very mundane (and very commonly required!) tasks so apparently poorly. And I'm left wondering what that is all about. I have noticed that using CFCs is "intrinsically" slower than other CF technologies (last time I measured such things), leading to all sorts of odd object-caching exercises, and wailing and gnashing of teeth, so perhaps leveraging one CF quirk to work around another CF quirk is actually... well... strangely appropriate.
Anyhow... I digress.
Serious question to Sean. My former boss has leapt on your comments at CFUnited, and has only really heard the "performance" side of things. I've pointed him at your comments about "it's not for performance benefits!!", but he's selective in what he chooses to listen to (hey: we're all a bit like that, so no worries). I still work with his software, and I'm concerned about the CFC auto-documentation suddenly going from "poor" to "diabolical", if they decide to whack out all their REQUIRED, RETURNTYPE and TYPE attributes.
I suggested ONE potential solution would be to leverage the fact that one can put any attribute one wants into a <cffunction> or <cfargument> (not sure about the latter?) tag. So one could then use REQUIRE, RETURNS and DATATYPE (or something) simply as metadata which can then be used in the component browser templates instead of the default (slow-to-perform ;-) ones. But I seem to recall at some point someone might have said something along the lines of (is that vague enough for you?) doing that is "bad". Do you have a position?
Do you have any suggestions as to an alternate solution (short of just sticking the equivalent info in the HINT, I suppose)?
Cheers.
--
Adam
4 Sean Corfield // Jul 4, 2006 at 5:45 PM
If I'd known the lemming-like behavior this would have caused, I would never have mentioned the performance issue. I wish I hadn't.
Frankly, I wish I'd never agreed to give this talk at all.
5 Ruud Hermans // Jul 5, 2006 at 12:25 AM
There are people, however, who do understand your point and do put it to good use. Rest asure, plenty of those exist.
If no one ever shared their wisdom in order to prevent lemming-like behaviour, the world wouldn't have gotten very far, now would it?
Just my 2c
Ruud
6 Adam Cameron // Jul 5, 2006 at 1:48 AM
Let's forget the term "duck typing" for a tick - I understand how you're annoyed people have missed your point on that one.
Now. Let's look at the issue of "things seem to run faster, in some situations QUITE A BIT FASTER, if you remove the type checking and requiredness checking from <cffunctions> and <cfarguments>".
What's got your back up so much about people being keen to investigate this?
I think people have to focus on performance tweaking in CF, and it seems it can be quite slow doing quite ordinary things. I've investigated a few things I've found slow on CF, running equivalent code on PHP. And PHP hoses it. And I'm not prepared to make any claims about being a great developer, but I certianly think my 5yrs of CF stacks up compararively well to my 1wk of PHP. Colleagues of mine have run identical CFML code on CF and BD, and running the code on the .net flavour of BD was "definitely a lot quicker" than running CF. And he had suspicions that just the Java version of BD was quicker too (no figures to demonstrate this, sorry).
Obviously performance is not the whle story - or even most of the story - when comparing CF with other platforms, but the reality is that is is an important issue.
From my experience, I think it's reasonable for people to be concerned about performance in CF, and accordingly natural for them to be keen to hear about how to tweak performance.
It's just a shame they found that part of your presentation's subject more interesting that the topic itself :-(
--
Adam
7 Luis // Jul 5, 2006 at 7:24 AM
1) Just because Duck Typing is faster in CF7 doesn't mean that this will be the case in future versions.
2) Off the top of my head, I can think of one place Duck Typing can help reduce coupling without really sacrificing documentation. for those who are exploring or using ColdSpring. Think back to the example in the documentation of a shopping cart component that uses a taxCaculator. In the example, even though ColdSpring was managing the dependency, the shopping cart manager had a fully qualified type listed meaning that if you wanted to for example substitute in AdvancedTaxCalculator.cfc for TaxCalculator.cfc you would have to change both the coldspring.xml and your shopping cart manager. Simply omitting that type attribute in the cfargument, allows ColdSpring to fully manage that dependency, and since you can find out exactly what component is being sent via coldspring.xml, you're not really giving up too much in the documentation arena. [besides, we all use hint, right? ;^) ]
Leave a Comment