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]
