isNumeric should test whether a given value is a number. It's debatable whether it should test whether a given value is both not null and a number, but CFML is such that it doesn't matter. Personally, I'd say that isX functions should return false for null values. Anyone know offhand how Java's instanceof operator works regarding null?
If I have an integer column in a database, I damn well better never get a string back from querying it. Ick. Give me a number or null (which is a 'nothing' of every type, including number). Why should I even bother to see if it's a number? I know it's a number. No sense in checking to see if it's a date (or anything else) either; I know it's a number. That's my point. Why should I have to go testing the value (treating it as a string!) to see if it's a number? If I'm testing user input, it is impossible to get anything except strings. You'll never get null, you'll never get a number, you'll never get complex data. You only get strings. In that case, you need to be able to determine if a given string is actaully a number, and isNumeric is appropriate. Different uses for different scenarios. Null indicates that no value exists, the empty string for an input value means [most likely] that a value wasn't provided. cheers, barneyb On 5/13/05, Ben Rogers <[EMAIL PROTECTED]> wrote: > > Yeah, you're completely missing the point. You're explicitly relying > > on CF's interpretation of null to be a non-numeric simple value (i.e. > > the empty string), rather than actually checking to see if the field > > is null (which is what you should be doing). > > Perhaps I'm missing the point because you make blanket statements such as > this without explanation. Why is it better to check that a childID is not > null rather than check to see if it is numeric? The following seem pretty > equivalent to me: > > <cfif not isNull(childID)> > > <cfif isNumeric(childID)> > > I should say that they are equivalent with the exception that the second > seems easier to read and actually performs some level of validation of the > on the data. > > > Either way, you're > > testing to see if some field returned from the DB is the empty string, > > and assuming that the empty string means that the field was actually > > NULL. > > Enter the straw man. You've completely misrepresented what I said. > isNumeric() does not test to see if a string has zero length. It checks to > to see if the value can be converted to a numeric data type. That's > fundamentally more useful that checking to see if something is not unknown > (i.e. not a null value). It's a much safer approach to say isNumeric() > rather than isNull() because the former validates what the data is while the > latter only validates one thing it is not. > > Assume for a moment that you have a form which allows you to add and edit a > record. In one instance, the data comes from the request, in the other, the > database. The request is not going to hand me null values. I'm going to get > strings that I'll need to type check (isDate(), isNumeric(), etc.) before > attempting to format or encode them. You're arguing that it's better to > check that a value is not null, which means I'm left with the following: > > <cfif not isNull(someDate)> > > <cfoutput>#dateFormat(someDate)#</cfoutput> > > Now, what if the user enters a value that is not a date. I better check for > that: > > <cfif not isNull(someDate)> > > <cfif isDate(someDate)> > > <cfoutput>#dateFormat(someDate)#</cfoutput> > > How's that better than just: > > <cfif isDate(someDate)> > > <cfoutput>#dateFormat(someDate)#</cfoutput> > > > I'm not going to argue that CF is wrong; CF's strength is in how it > > abstracts complexity into simple things, and this is a good example. > > It's just kind of frustrating that you can't do it the "right" way if > > you want to. > > I'd like to see some code that clearly demonstrates an advantage to the > "'right' way". I've seen a lot of code in languages that do support null > values. In the presentation and business tiers, it adds a great deal of > complexity and, with it, points of failure. I see no benefit. > > 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]
