@Peter, I agree. Implicit or not, I find no issue with assuming that zero is
false and any other value is true. That's been true in every DB I've used,
whether the true is 'true' or '1' or '-1', the false is always '0' and my code
is generally single use at any rate.
RE: Barney,
I disagree. I find implicit boolean conversions to be cleaner and easier to
read (and are a feature of the language).
But, furthermore, the implicit boolean conversion says even more about the
statement than any comparision. If you see:
this implies that there is a strict set
; tends to add a bit
more explanation as to the intent of the code. However, it does add a
few keystrokes.
Mike
-Original Message-
From: Justin Scott [mailto:jscott-li...@gravityfree.com]
Sent: Friday, January 09, 2009 2:19 PM
To: cf-talk
Subject: Re: anybody see this before?
Barney Boisve
Barney Boisvert wrote:
> Don't do that. What's happening is that the number
> (isthere.recordcount) is being implicitly converted to a boolean for
> the CFIF to process. Implicit conversion where the destination type
> is something besides String is almost always the devil, end even if
> it's Str
And I'll chime in on Peter's side. I like boolean shortcut evaluation
and consider it in the same class as well known shortcuts for things
like autoincrement operator (i++). I can understand those that argue
for explicit comparisons and there is certainly nothing wrong with it.
But yeah, its just a
> There are functions where implicit conversion shouldn't be used:
> DateCompare(), Max(), etc - those ones should be compared against the
> expected value.
>
> But when the boolean conversion is known and unambigious - Query.RecordCount,
> Len(), ArrayLen(), find(), etc - it is perfectly accept
>"isthere" would be a variable reference to a query object with that name.
Also, it is probably worth pointing out that "isthere" is an awful name to use
for a query variable, and it should be changed to something more meaningful.
(Though without seeing the original code it's not possible to know
Yes, I do it, and disagree with Barney on implicit conversion always being evil.
There are functions where implicit conversion shouldn't be used: DateCompare(),
Max(), etc - those ones should be compared against the expected value.
But when the boolean conversion is known and unambigious - Query
Duh. Missed that. There sure is a query named isthere. I thought
isthere.recordcount was a function of some kind.
-Original Message-
From: Kris Jones [mailto:kris.jon...@verizon.net]
Sent: Friday, January 09, 2009 2:58 PM
To: cf-talk
Subject: Re: anybody see this before?
"is
"isthere" would be a variable reference to a query object with that
name. "recordcount" is an attribute of a query object.
isthere.recordcount would evaluate to a numeric of 0 or greater. If 0,
it would evaluate in a boolean to false. Otherwise it would evaluate
as true.
No mystery here. Or am I ju
Don't do that. What's happening is that the number
(isthere.recordcount) is being implicitly converted to a boolean for
the CFIF to process. Implicit conversion where the destination type
is something besides String is almost always the devil, end even if
it's String it's still the devil sometime
Working with some old code and found this.can't seem to find a reference via
adobe.com or google or books. Is it old or am I just missing something.
It does work.
Seems a clean way to check.does anyone use this?
Mark
~~
12 matches
Mail list logo
