Nathan, The problem, imho, is that we lack a null in CF. So anything we do is going to be a kludge. The question is: what's the least kludgy kludge? For me, having hasX and hasY methods is REALLY kludgy, but it sounds like you find that more appealing.
It's funny we're having this discussion at this time because I'm putting out a newsletter this week talking about the benefits of having a BaseComponent class. I think this is important -- bordering on mandatory. I didn't introduce a BaseComponent class to deal with error messages for null components, but for a number of other reasons, primarily the lack of object identity in CFCs. Hal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass Sent: Wednesday, October 26, 2005 12:32 PM To: [email protected] Subject: Re: [CFCDev] CFC return types Well, we can agree to disagree then ;) I'm tempted to engage in a debate here, but I'll resist the temptation. Well, OK, maybe just one more round..... > 2. documentation: disagree; I think it's pretty easy to document what > isNull does and doesn't require too much documentation It's not that you can't document what isNull does, it's that you now need to explicitly document all of the "dangling" properties -- which I suppose you could do with CFPROPERTY, but it's still two different things to document and more for the developer to have to dig into. > > 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. It's not that they can't understand isNull("spouse") -- it's that they will see documentation for isNull(string) [the "signature" of the method does not include "spouse" as the option, it will merely say there is a string there] and then need to go digging for what the properties are. The name you are giving a specific property just feels a step closer to implementation details than the name of a method (which is by its nature an interface concern). I guess I'm just literally thinking about how I would be sitting there coding against the CFC documentation, and knowing quickly that there is a method called hasSpouse() seems faster than needing to dig one level deeper into documentation to find out the string "spouse" is the way to go. > > 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. Um, like I said, it would it take more work to get a useful error to happen -- and the fact that we now have to have a baseComponent involved, introducing inheritance dependencies just to get something like useful error messages seems proof of that point. > > 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. And yes, at the end of the day, it's just a bunch of code ;) > ---------------------------------------------------------- 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]
