> 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."
Just reread my message and realized that this paragraph ended up in the wrong spot. It wasn't in response to the quote that preceded it. It was a comment about returning nulls from functions with a returntype of something other than "any". My apologies if there was any confusion. I should really proof read my messages before I send them, not after. :) Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Ben Rogers > Sent: Thursday, May 12, 2005 8:07 PM > To: [email protected] > Subject: RE: [CFCDev] Null values (was CFC wish-list) > > > 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] ---------------------------------------------------------- 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]
