Hmmm...I'll have to defer to you on the difficulty of implemented null support in CFMX, but in BlueDragon it shouldn't be too hard if you assume that all pre-existing code treats null values as empty strings.
In fact, this is how BlueDragon is already implemented: we have an internal data type that represents null database values, and this null data type is automatically converted to an empty string as needed by the type system. Therefore, it should be almost trivial to add null support to BlueDragon via the NullNew() and IsNull() functions as I described in an earlier email (and to add an ALLOWNULLS attribute to CFFUNCTION as Ben suggested). If we could add support for nulls, interfaces, and maybe constructors to a maintenance update to BlueDragon 6.2 later this summer is that something people on this list would be interested in? Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield > Sent: Friday, May 13, 2005 1:13 PM > To: [email protected] > Subject: Re: [CFCDev] Null values (was CFC wish-list) > > Wow, there's so much stuff in this thread already - I'm going > to have to spend some time responding to many of the issues > raised here. > However, I'm going to start with Dave's post (because it's > the closest one to being on the mark). > > On 5/13/05, Dave Carabetta <[EMAIL PROTECTED]> wrote: > > At the end of the day, introducing interfaces and a concept > of a null > > is a massive undertaking from an engineering standpoint. > Sean Corfield > > has touched on this in previous threads (sorry, can't find direct > > references at the moment), and, while I don't have anywhere > near his > > level of Java expertise, common sense dictates to me that it's > > certainly not trivial. > > Yeah, I've been designing programming languages and building > compilers and interpreters for much of my 25 years in IT so > when I say that adding null to a language is a big deal, I'd > hope that people wouldn't just dismiss it and say "Oh, they'd > only have to change this and that to make it work!". More on > that in a minute. > > Interfaces. Yes, that would be nice. For me, interfaces would > be more important than null: I bump into the lack of > interfaces more than I bump into the lack of null. And, > before anyone comments on my programming style, bear in mind > I started OOP in early '92 with C++ and picked up Java in > early '97 - I've built some large, mission-critical systems > including 24x7 embedded telco stuff. Yes, I've found null > very useful in a lot of that stuff but after three and a half > years of ColdFusion - all with CFCs - I haven't needed null > to the extent that it has prevented me from creating an > elegant solution. > > So what would it take to add null support? > > First off, every single construct in CFML that does type > validation (cfargument, cffunction returntype=, cfparam, > is*()...) needs to be able to treat null as any component > type. Probably need > isCustomFunction() to treat null as any function type too > (see where this gets into a discussion of semantics about > what could be a 'pointer' and what does 'null' really mean?). > > We've already got a null value we can return and pass around using > javaCast("null","") - yeah, some syntactic sugar here would be nice. > > Then every single place where CFML looks up variables needs > to change so that the following doesn't error out: > > <cfset var x = someObj.getNull() /> > <cfset var y = x /> > > Today, that will complain that x is not defined. Similarly: > > <cfset session.x = someObj.getNull() /> > <cfset variables.y = session.x /> > > will complain that x is not defined in session. > > Once that is changed, every built in function needs to be > examined to see what it should do if it is passed null - try passing > javaCast("null","") to a bunch of built in functions and see > what happens today... For most functions, passing null will > probably just throw a Java level NPE which may be acceptable > behavior but some functions will need to do something different. > > Then there's cfqueryparam and how it maps null values to NULL > in the database. Any tags and functions that deal with a > variable or expression by name (since they're not being > passed null but when they evaluate something they would get > null - as opposed to thinking the variable is just not defined). > > That's just off the top of my head... so it would touch every > piece of type checking code and every piece of variable > lookup and then there would be all the QA and, especially, > checking for backward compatibility (in particular, behavior > of isDefined() and > structKeyExists() may change because today CFMX treats a null > variable value or a null struct key value as being "not > defined" / "not present"). That latter point might make cause > some subtle bugs to be introduced in existing code (I know I > have code that relies on null values being treated as not > defined for isDefined()). > > > Let's face the facts: CFCs, by several accounts, just are not the > > "bread and butter" of what makes ColdFusion marketable. > > Agreed. Of the three or four hundred thousand ColdFusion > developers out there, I'd hazard a guess that only a small > percentage are actually using CFCs. We have several thousand > subscribers on cf-talk but not even all of them are using > CFCs yet. How many subscribers are here on CFCDev? And then > how many of those people using CFCs are really trying to > build complex OO stuff? > > Want a comparison with, say, C++? Three million developers > worldwide and anecdotal evidence suggests that less than half > of them are really writing OO code. That's a language where > classes have been available for twenty years. > -- > Sean A Corfield -- http://corfield.org/ > Team Fusebox -- http://fusebox.org/ > Got Gmail? -- I have 50, yes 50, invites to give away! > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > ---------------------------------------------------------- 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]
