> In many instances, allowing functions to return null values just shifts the > problem or, at least, the responsibility. This is why we so many null > pointer exceptions from Java and C#. They are proper OO languages returning > null values that the consumer is unprepared to handle.
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. 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. For example, say my mythical function actually needed to return a string, not an object. And the empty string was a potentially valid value. 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. 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. 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. cheers, barneyb On 5/12/05, Ben Rogers <[EMAIL PROTECTED]> wrote: > > It shouldn't be a debate, we aren't demanding that every > > CFC developer program in a OO fashion. We are just asking for small > > enhancements that would make our lives easier and our applications more > > robust. > > "Small enhancements" is a bit of an understatement. Adding the concept of > null values to a 10 year old language that has always treated nulls as empty > strings is no small thing. I don't even see how it's possible. Nevertheless, > I think it's a great feature request. > > The reason this stuff is "debated" is because there's a good chance you're > going to have to sacrifice backwards compatibility for nulls and interfaces. > VisualBasic had to undergo some pretty severe growing pains to become a > "proper" OO language. That was 5 years ago and the VisualBasic 6 users are > still revolting. > > I think both you and Hal have overestimated the need for null values. Hal's > statement was, "Without this, you can't protect against runtime errors," > which makes it sound as if support for nulls is the panacea for all runtime > errors -- hence my confusion. > > In many instances, allowing functions to return null values just shifts the > problem or, at least, the responsibility. This is why we so many null > pointer exceptions from Java and C#. They are proper OO languages returning > null values that the consumer is unprepared to handle. > > Don't get me wrong, I'm not arguing that support for null values, and, in > particular, returning null values from functions, is a bad thing. Like I > said, I think it's a good feature request, but I question how useful it will > be. And even if it is incredibly useful, as far as I can tell, there are > remarkably few applications making extensive use of components, which is > probably where this feature would be the most useful. > > > I think this is one area that Blue Dragon could leapfrog CFMX, > > and I would seriously think about switching if they did implement > > interfaces and null in a proper fashion. > > I'm much more concerned about compatibility between the implementations. I > hope that New Atlanta gets more serious about compatibility, not less. > > Ben Rogers > http://www.c4.net > v.508.240.0051 > f.508.240.0057 -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- 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]
