> 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]
