> In programming, it is a best practice to initialize all variables with a > default value.
I'd take issue with that. I consider NULL a perfectly legit situation. yes, DBA's arguing over whether their database should contain NULLs or not takes on religious overtones (like curly braces being written java or C++ style) but when it comes to simple and complex datatypes, nothing beats checking for NULL to really know what the value "isn't". What's the default (unitialised) value for an integer when it's domain of legetimate values could be positive, zero or negative? in C#.NET (v2.0) it's NULL. In v1.1 it's zero. I've had to use a work around for earlier code of "Int32.MinValue" (negative 2 million-odd) to give some sort of sentinal value -just to survive. The result is a hack-job when they should have got it right first time (before v2.0). Same thing for DateTime. In CF it's easy. if you're expecting an int and get an empty string then that's a good indication that *any* int value doesn't exist - as good as a NULL. Same for DateTime. You certainly can't convert an integer "place holder" to an empty string in a strongly typed language.... chalk up another selling point for CF. <cfif isIntNull(intValue)> <!--- UDF checking for empty string ---> <cfif isDateNull(dtValue)> <!--- as above ---> <cfif StructIsEmpty(stValue)> <cfif ArrayIsEmpty(arrValue)> in fact the only thing I'm not happy with (so far) is a CF version of <cfif CFCisEmpty(cfc)> meaning if (myObject == null) // object created but not initialised with values. > Why does a object need a notion of NULL? perhaps to indicate that the underlying db record for it doesn't exist and you don't want to throw an error because that's perfectly normal? and that you've abstracted the system so much, the whole notion of a "database" is irrelivant so number of recordset rows returned (one or zero) is meaningless? eh, my 2c barry.b On 4/15/06, Joseph Flanigan <[EMAIL PROTECTED]> wrote: > Under cfquery, a SQL NULL constant is allowed - see below. > > Why does a object need a notion of NULL? A NULL is a name-space > without a value-space. In a DB, each tuple is a structure, and some > keys may have no value, but the structure exists as the > representative physical record. Consequently, a NULL has meaning > within the DB as a key with no value-space representation, that is, > no bits being written to the disk. > > Consider an object to be a structure. Keys in the object have value > when instanced either with load defaults or sets. Perhaps a key that > is isDefined but without value could be considered a NULL. But the > very notion of a NULL is that of a value. (Even in DB there are > special test for it -- IS NULL.) In programming, it is a best > practice to initialize all variables with a default value. In CF, > all simple variables are really string. As far as I know, in CF all > variables and keys default to empty value. Within CF the notion of > NULL does not exists. But yes, empty can be considered a NULL in > cases when dealing with a DB. Look at Rob Brooks-Bilson's isNull > function on CFLib. > > <cfset name = "John Doe" > > <cfset address = "" > > > <cfquery name="demo"> > DECLARE @Name varchar(50) > SET @Name = '#name#' > > DECLARE @Address varchar(50) > SET @Address = > <cfif len(address)> > "#address#' > <cfelse> > NULL > </cfif> > > INSERT INTO Contacts > ( > [Name], > [Address] > ) > VALUES > ( > @Name, > @Address > ) > </cfquery> > > At 06:47 AM 4/13/2006 Thursday, you wrote: > >Yes, and although HTML doesn't have a null per se, there is a difference > >between www.example.com?blah= vs. www.example2.com?blah=%27%27, which CF > >does recognize, so this is kind of a null, without strict typing. > > > >One way to pass strings with strict typing is to use JS or AS and > >produce an xml string to a schema. Yuk, but it can be done. > > > >Ron > > > > >>> [EMAIL PROTECTED] 4/13/2006 8:32 AM >>> > > > >But what about when we start dealing with Flash Forms where you bring > >ActionScript and strict datatyping into play? There is going to be a > >time and place, maybe with Flex, where we will see null values and not > >empty strings. If you move into Flash Forms (Flex Lite), you will see > >strict-datatyping come into play. > > > >my 2 cents. > > > >ap > > > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >Behalf Of Nando > >Sent: Wednesday, April 12, 2006 4:09 PM > >To: [email protected] > >Subject: Re: [CFCDev] How to deal with "empty" objects without Nulls? > > > > > > > >When working with web applications, i think it's important to keep in > >mind that a form only submits variables as strings. There are no data > >types in HTML. So any data that your users submit to the app is going to > >originate as a string. > > > >And ColdFusion doesn't have a concept of null, so i believe you'll get > >an empty string in CF when a null is returned from a database query. > > > >To me, that translates into a simple understanding: trying to strong > >type all your arguments in CF is going to be laborious, maybe a waste of > >time. So in cases where a value could be null in the database, or could > >be submitted from a form, to me, the argument type should be "any" or > >"string", because that's the reality, and any validation that should > >happen before persisting it or manipulating the variable needs to be in > >a validate method. > > > >You can also consider strong typing your arguments and catching the > >wrong type errors, but there's no simple, clean way to do that. Strong > >typing arguments that can possibly receive other types in normal > >application flow implies handling wrong type errors as part of the > >application flow. It's not really an application exception. > > > >To me, that's not right. Error handling isn't for normal application > >flow. So strong typing in these cases doesn't seem right to me. > > > >I find it easier and cleaner, in CF's loosely typed environment that > >meshes well with HTML's typeless environment, to just go with the flow > >and loosely type my arguments in all cases where the type is not fixed > >in stone, and handle validation after the variable is passed into the > >method. > > > >If a real exception happens at some point that involves that loosely > >typed argument, a runtime error will be thrown anyway. It might not be a > >wrong type error, but something else will error out a few milliseconds > >later. > > > >Does that make sense? > > > >Daniel Roberts wrote: I have objects that have instance variables with > >setters/getters requiring types such as uuid and date. If the object is > >"blank" the variables will be empty strings, which cause errors when > >getting or setting to blank, or bad data if I start them off with values > >to match their types (1/1/0001 or AAAA-AAAA-AAA etc) which just feels > >wrong. The way around this is to allow any type of data through the > >setters and getters with some extra custom validation code or > >getting/setting instance data structs. Neither of these seem right. Am I > >missing something here? > >---------------------------------------------------------- > >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). > > > >An archive of the CFCDev list is available at > >www.mail-archive.com/[email protected] > > > >-- > > > > > >Aria Media Sagl > >CP 234 > >6934 Bioggio > >Switzerland > >www.aria-media.com > > > > > > > > > > > >______________________________________________________________________ > >This email has been scanned by the MessageLabs Email Security System. > >For more information please visit http://www.messagelabs.com/email > >______________________________________________________________________ > >---------------------------------------------------------- > >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). > > > >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). > > > >An archive of the CFCDev list is available at > >www.mail-archive.com/[email protected] > > ----------------------------------------------------------------------- > > Switch_box MediaFirm, Inc. > www.Switch-box.org Loveland, CO USA > > > > ---------------------------------------------------------- > 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). > > 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
