So we have (at least) three different methods for handling the lack of null: throw an exception, have hasX methods for every getter, and have a generic isNull method. None of them seem ideal. I wish we could harness our combined energy to get Macromedia to provide a null and be done with it.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Wednesday, October 26, 2005 12:53 PM To: [email protected] Subject: Re: [CFCDev] CFC return types > 3. requires greater knowledge of implementation: disagree. If someone > is going to use an object, they're certainly going to need to know > something about it -- not its implementation but its interface (which > means method signatures). Do we think that if someone sees a > getSpouse(): Person method, there will be any difficulty in understanding what isNull('spouse') will do? This assumes that getSpouse is based on a 'spouse' instance variable, which may or may not be the case. For example, getSpouse might do a lookup on the spouseID (an instance variable) and return the resulting object, optionally caching it. All of a sudden you don't have a 'spouse' instance variable at all, so a generic isNull isn't going to work. Consequently, you're either tying your interface to the implementation, or going to have a very hackish isNull method for dealing with the special properties. Same argument applies to point 4, regarding useful error messages; you have to have per-CFC (the static class) knowledge of what are instance variable-backed properties, and which are ethereal properties. cheers, barneyb On 10/26/05, Hal Helms <[EMAIL PROTECTED]> wrote: > I was going to say "good points, Nathan" (and I may still) but let's > examine your points. > > 1. more descriptive: agree, although I think isNull('spouse') isn't > too bad > > 2. documentation: disagree; I think it's pretty easy to document what > isNull does and doesn't require too much documentation > > 3. requires greater knowledge of implementation: disagree. If someone > is going to use an object, they're certainly going to need to know > something about it -- not its implementation but its interface (which > means method signatures). Do we think that if someone sees a > getSpouse(): Person method, there will be any difficulty in understanding what isNull('spouse') will do? > I can't see this as much of a point against isNull. I certainly don't > see this as any higher learning curve. The getSpouse(): Person method > already guarantees that spouse is a Person. That's the only contract > that needs to be maintained. There's no extra risk if an implementation changes. > > 4. misspelling of property name will throw an unuseful error: again, > disagree. I have a BaseComponent CFC that has isNull(propertyName: string): > boolean. If someone asks for a property that doesn't exist, it throws > a custom error of type PropertyNotFound. That makes for pretty easy > debugging for the end developer. S/he'll see the cause of the error immediately. > > So, while I don't vehemently disagree with what you say, I don't think > there's much cause to litter code with hasX(): boolean, hasY(): > boolean, > hasZ(): boolean. At least, I'm not convinced. I think a consistent > isNull() method, implemented in a base component, works fine. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 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] ---------------------------------------------------------- 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]
