Of course, we won't really know until Macromedia implements both and tells us which was more difficult. :) It's possible they could implement support for this feature in a very shallow way by simply allowing a function with returntype="ComponentName" to return nothing or an empty string. However, that wouldn't solve the problem for all those folks who want to be able to pass null values to java objects.
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 David Ross > Sent: Thursday, May 12, 2005 6:28 PM > To: [email protected] > Subject: RE: [CFCDev] Null values (was CFC wish-list) > > odd... I thought of interfaces as MUCH easier to implement than null, > since interfaces only apply to CFCs and null support would be > language-wide. > > If I had to choose one, I'd take interfaces, but I want BOTH :) > > -Dave > > >>> [EMAIL PROTECTED] 05/12/05 6:11 PM >>> > I understand that adding interfaces could be a big deal, but I would > think > that you could add a null value fairly easily. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Ben Rogers > Sent: Thursday, May 12, 2005 5:28 PM > To: [email protected] > Subject: RE: [CFCDev] Null values (was CFC wish-list) > > > 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 > > > > > ---------------------------------------------------------- > 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] > > > > > > ---------------------------------------------------------- > 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]
