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.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Nathan Dintenfass
Sent: Wednesday, October 26, 2005 5:40 AM
To: [email protected]
Subject: Re: [CFCDev] CFC return types
A few thoughts on Hal's question....
hasSpouse is much more descriptive semantically -- makes for more readable
code.
hasSpouse is simpler to document (especially given CFC
auto-documentation) than isNull, where I have to then go about documenting
various properties.
isNull seems a step closer to requiring the developer to know more about the
implementation of your component rather than just the interface.
hasSpouse is a single "layer" to learn for the developer, whereas isNull
requires learning both that method and the possible attributes that are
appropriate to ask for. This both risks breaking clean encapsulation [and
makes implementation harder to change] and requires a higher learning curve
for developers.
isNull("spuse") [notice the misspelling] is going to either not throw a
useful error or will take more work to have it throw a useful error.
Whereas hasSpuse() [same spelling error] will throw a meaningful error
without needing to do any extra work. This makes debugging much easier for
the end-developer who has to use the component.
Hal Helms wrote:
> Why not just have an isNull(propertyName) method rather than litter
> classes with hasSpouse, hasX, has Y?
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of David Ross
> Sent: Tuesday, October 25, 2005 11:36 AM
> To: [email protected]
> Subject: RE: [CFCDev] CFC return types
>
> the cool thing is that by having a hasSpouse() and a getSpouse() that
> throws NotMarried, you leave the choice up the client (thus it's a
> good practice to put "Throws: NotMarriedException when there is no spouse"
> into the getSpouse()'s hint).
>
> -Dave
>
>
>>>>[EMAIL PROTECTED] 10/25/2005 9:56:13 AM >>>
>>
>>I think that's Barney's point. If you're going to call getSpouse(),
>
> you
> should already know that the person has a spouse. You shouldn't call
> getSpouse() and then check the result to see if a the person had a spouse.
> Nor should you call getSpouse() and look for an exception to let you
> know that person didn't have a spouse.
>
> Patrick's was one of the best explanations I have seen so far.
>
> M!ke
>
>
> ----------------------------------------------------------
> 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]
>
>
>
> -----------------------------------------
> CONFIDENTIALITY NOTICE: This email and any attachments may contain
> confidential information that is protected by law and is for the sole
> use of the individuals or entities to which it is addressed. If you
> are not the intended recipient, please notify the sender by replying
> to this email and destroying all copies of the communication and
> attachments. Further use, disclosure, copying, distribution of, or
> reliance upon the contents of this email and attachments is strictly
> prohibited. To contact Albany Medical Center, or for a copy of our
> privacy practices, please visit us on the Internet at www.amc.edu.
>
>
>
> ----------------------------------------------------------
> 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]
>
>
>
>
----------------------------------------------------------
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]
