> I HAVE to respond this statement. Having or not having null doesn't > affect this issue at all. If i have null, I return it. If I don't > have null, I return "something" (like the empty string). In either > case, the calling code needs to be able to handle both scenarios.
Correct, but I believe you're over simplifying a bit -- or at least leaving out the transition from one environment to another. Right now, if a function declares a return type of "any", then I know that I need to program defensively and check the data that's returned. If it declares a return type of "Customer", then I know that the value returned from the component will be a component of type "Customer". No further checking is required on my part. If, hypothetical speaking, ColdFusion allowed you to return null values from a function with a return type of "Customer", then any code that now expects an object of type "Customer" needs to be changed to expect an object of type "Customer" *or* a null value. When you first perform the upgrade to this hypothetical version of ColdFusion, there won't be a problem. But as you change and modify functions over time, you will almost certainly introduce situations, either intentionally or unintentionally, that cause functions to return null values to code written when ColdFusion did not support nulls. > Having null makes this easier, because you have a specific value to > test against, and more importantly, it's a value that cannot be > confused with any other value. Personally, I believe using null values this way is a mixed blessing in most languages. I would like the ability to return a null value. However, I think I should have to make that part of the method signature and have it default to "no, this method will not be returning null values." > For example, say my mythical function actually needed to return a > string, not an object. And the empty string was a potentially valid > value. By that, do you mean that NULL has some kind of intrinsic value? If so, then that may be a poor design. NULL already has a meaning. I would avoid overloading it with another. > You see this all the time with query recordsets. CF makes no > differentiation between null and the empty string. In some cases you > can differentiate manually (like if a value of a column you know HAS > to be numeric is the empty string, then that emtpy string means null), > but by and large, you're stuck with incomplete information. I'll probably need a more specific example than this because I'm having trouble thinking of a situation where NULL is more useful (in the presentation or business tiers) than a zero length string. I'm not saying that there's never a case. I just can't think of one. > Bottom line, if CF is going to expose typing at all, it needs to have > null, or you're undermining and severely crippling that very typing > concept. Many ColdFusion apps function fine today and have for the last 10 years without it. So, it would seem that it's not as simple as that. That said, I think the introduction of ColdFusion components has moved ColdFusion more into the business tier where, I believe, null values are more important than they are in the presentation tier. Again, to a certain extent, I'm playing devil's advocate. Though I don't like the example you've provided, I do think there are many situations where I would like to return null values from functions -- with the aforementioned bit about affecting the method signature. > Regarding interfaces, I think that debate is a fundementally different > one. Interfaces are nice, and make for cleaner OO design, but they're > by no means required. Null, however, is required by a typed system. > I'd almost rather see CF remove typing completely than continue > forward without null, because, yes, it is that important. Maybe the current state of affairs doesn't bother me so much because I don't look at these things as part of a "type system". I look at the "returntype" and "type" attributes as a built-in form of data validation. Personally, I do not want to see strong typing in ColdFusion or even an overt "type system". I think that one of the things that makes ColdFusion so strong (no pun intended) in the presentation tier is that it is weakly, dynamicly typed -- and doesn't force the programmer to differentiate between null values and zero length strings. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
