On 10/26/05, Hal Helms <[EMAIL PROTECTED]> wrote: > 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] > > >
-- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us ---------------------------------------------------------- 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]
