At 11:59 AM 4/20/4, Johnny Le wrote:
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation that I am
not aware of.
Watch out for intrinsic conversions... if
Is it a bug or am I Shakespeare?
To bug, or not to bug, that is the question...
--
___
See some cool custom tags here:
http://www.contentbox.com/claude/customtags/tagstore.cfm
Please send any spam to this address: [EMAIL PROTECTED]
Thanks.
[Todays Threads]
22, 2004 3:44 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Is it a bug or am I Shakespeare?
To bug, or not to bug, that is the question...
--
___
See some cool custom tags here:
http://www.contentbox.com/claude/customtags/tagstore.cfm
Please send any
Schneegans [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 3:44 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Is it a bug or am I Shakespeare?
To bug, or not to bug, that is the question...
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
Because (20 and true) returns true, so (true and 20) should return true.
Barney Boisvert wrote:
If you agree that 20 is true, then you implicitly agree that 20 is a boolean
value.With that, how can you argue that 20 is not a valid result from a
boolean _expression_?
[Todays Threads]
[This
: Re: Is it a bug or not a bug?
So all those people using cfif Len(Trim(value))IS
TRUEcfelseIS FALSE/cfif are doing it wrong? I dont think
so... this is valid and good practice.
Please don't mix up everything: it IS correct to use your
statement, because len(...) will be converted
You're still missing the fundemental point about a loosely typed language.
I'm not missing anything. This has nothing to do with lousely or not.
Lousely typed does not mean the type does not exist, what it means is that the variable will be converted during execution to a type suitable according
and usually benefit from the
advantages that the compromise the language designers made allowed.
Cheers,
barneyb
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 21, 2004 11:19 AM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
You're still
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation that I am not
aware of.
CF uses short-circuit boolean evaluation. So it'll either stop the moment it
true = 1 = yes
false = 0 = no
afair
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 2:59 PM
To: CF-Talk
Subject: Is it a bug or not a bug?
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5
Yes it's a bug, I have submitted it. Use #((4*5) and true)# until it
get's fixed.
Johnny Le wrote:
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation
608.270.9770
_
From: Dave Carabetta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 2:03 PM
To: CF-Talk
Subject: RE: Is it a bug or not a bug?
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation that I am not
aware of.
CF uses short-circuit boolean evaluation. So it'll either stop the moment it
IIRC, this is new in CFMX.
Doug
-Original Message-
From: Mark W. Breneman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 3:15 PM
To: CF-Talk
Subject: RE: Is it a bug or not a bug?
Does MM officially support performing mathematical calculations between #
signs? I was sorta
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation that I
am not
aware of.
CF uses short-circuit boolean evaluation. So it'll either stop the
moment it
Yes I'm sure they do. I don't know about good or bad, I really haven't
thought about it. It does work.
Mark W. Breneman wrote:
Does MM officially support performing mathematical calculations between #
signs? I was sorta under the impression that this was considered not a good
practice.
This is not a bug, it's just part of using a loosely typed language.
Non-zero values are true, and zero is false.A short-circuited boolean
evaluation returns the value of the last _expression_ that is evaluated.
Note, that whether the first test returns 'true' or '20', both are true
values, so it
-Cold Fusion Developer
-Network Administrator
Vivid Media
[EMAIL PROTECTED]
www.vividmedia.com
608.270.9770
_
From: Dave Carabetta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 2:03 PM
To: CF-Talk
Subject: RE: Is it a bug or not a bug?
#(true and 4*5)# returns 20.
#(false and 4*5
Does MM officially support performing mathematical calculations between #
signs? I was sorta under the impression that this was considered not a good
practice. Regardless it is handy.
As of CFMX you can. Good or bad practice is your call though.
Regards,
Dave.
[Todays Threads]
[This Message]
Run this:
cfif true and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and truetruecfelsefalse/cfifbr
cfif false and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and falsetruecfelsefalse/cfifbr
br
cfoutput#true and (4*5)#/cfoutputbr
cfoutput#(4*5) and true#/cfoutputbr
cfoutput#false and (4*5)#/cfoutputbr
Administrator
Vivid Media
[EMAIL PROTECTED]
www.vividmedia.com
608.270.9770
_
From: Bryan F. Hogan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 3:32 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Yes I'm sure they do. I don't know about good or bad, I really haven't
thought
#(true and 4*5)# returns 20.
#(false and 4*5)# returns false.
#(4*5 and false)# returns false.
#(4*5 and true)# returns true.
Is it a bug or it is using some sort of _expression_ evaluation that I am
not
aware of.
CF uses short-circuit boolean evaluation. So it'll either stop the
I don't know, I could be wrong on it being supported. But I deff have
not heard of it not being supported. It does seem to be broken in this
case though.
I don't know what you would call it. Output Expressioning? ;-)
Mark W. Breneman wrote:
I thought I had seen someone on this list, when MX
Run this:
cfif true and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and truetruecfelsefalse/cfifbr
cfif false and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and falsetruecfelsefalse/cfifbr
br
cfoutput#true and (4*5)#/cfoutputbr
cfoutput#(4*5) and true#/cfoutputbr
cfoutput#false and (4*5)#/cfoutputbr
It wouldn't surprise me if it disappeared again in a future version.
It used to be in CF3.x, and was removed in CF4.x.
Sure is handy though.
- Original Message -
From: Mark W. Breneman [EMAIL PROTECTED]
Date: Tuesday, April 20, 2004 1:46 pm
Subject: RE: Is it a bug or not a bug?
I
20 *is* true.
A little precison: 20 EVALUATES to true when it is converted, but 20 is 20 and true is true.
--
___
See some cool custom tags here:
http://www.contentbox.com/claude/customtags/tagstore.cfm
Please send any spam to this address: [EMAIL PROTECTED]
[EMAIL PROTECTED] 04/20/04 03:55PM
snip
Interesting. I would have guessed that both sets would have returned the
same exact results. That, to me, is indeed a bug.
Dave,
Could you explain why you are sure this is a bug, and not just an unexpected casting issue?
Why should #1 and 20#
This is not a bug, it's just part of using a loosely typed language.
Well... your right that it is part of using a loosely typed language, this implies that the language has to convert automatcally variables and expressions in order to perform a statement, but when the laguage converts to the
If you are asking whether it is true or false, then it is true.But if you ask what is value of that _expression_, then it is 20.I think that is two different questions.So you get two different answers.
Johnny
Run this:
cfif true and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and
-
From: Jerry Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 4:15 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
[EMAIL PROTECTED] 04/20/04 03:55PM
snip
Interesting. I would have guessed that both sets would have
returned the
same exact results. That, to me
it'll return the last value evaluated in the _expression_.
This IS the bug: it should return the type implied by the operator in the _expression_.
in true and 4*5, CF has a boolean and a boolean operator, It thus has to evaluate 4*5, THEN convert it to a boolean in order to complete the boolean
Claude Schneegans wrote:
20 *is* true.
A little precison: 20 EVALUATES to true when it is converted, but 20 is
20 and true is true.
Point taken.Definately important if you ever compare things to true.
--Ben Doom
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
In general, boolean expressions should return boolean values
(yes,no,true,false).This is a bug.
Paul Kenney
[EMAIL PROTECTED]
916-212-4359
-Original Message-
From: Samuel R. Neff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 1:20 PM
To: CF-Talk
Subject: RE: Is it a bug
]
Sent: Tuesday, April 20, 2004 1:46 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Run this:
cfif true and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and truetruecfelsefalse/cfifbr
cfif false and (4*5)truecfelsefalse/cfifbr
cfif (4*5) and falsetruecfelsefalse/cfifbr
br
cfoutput
Schneegans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 3:24 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
it'll return the last value evaluated in the _expression_.
This IS the bug: it should return the type implied by the operator in the
_expression_.
in true and 4*5, CF has
You are anding a boolean and an integer, and getting an integer out.
This IS the bug, a loosely interpretor should always convert operands to fit the operator, not the contrary.
If you are anding a boolean and an integer, the and is a boolean operator, the boolean is ok, the integer is the alien,
http://www.macromedia.com/go/team
-Original Message-
From: Jerry Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 4:15 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
[EMAIL PROTECTED] 04/20/04 03:55PM
snip
Interesting
Blog http://www.rewindlife.com
TeamMM http://www.macromedia.com/go/team
-Original Message-
From: Jerry Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 4:15 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
[EMAIL
If you want a boolean value returned, you can use yesNoForamt()
Well, the purpose of the yesNo() function is to convert a boolean value to a text representation, not to convert an integer which should have been a bolean in the first place.
A _expression_ with two operands and one boolean operator
It looks like the operator decides the type for the result for
everything except the AND operator.
Even OR works as you say it should.
#1 + true# 2
#true + 1# 2
#1 and true#true
#true and 1#1
#true or 1#true
#true + true#2
#true + false#1
#true a#truea
#a true#atrue
#true and
[EMAIL PROTECTED] 04/20/04 03:55PM
snip
Interesting. I would have guessed that both sets would have returned the
same exact results. That, to me, is indeed a bug.
Dave,
Could you explain why you are sure this is a bug, and not just an
unexpected casting issue?
Actually, it's not. I didn't
, 2004 3:32 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Yes I'm sure they do. I don't know about good or bad, I really haven't
thought about it. It does work.
Mark W. Breneman wrote:
Does MM officially support performing mathematical calculations between #
signs? I was sorta under
why would you use 5*4 in an _expression_?
I suppose the _expression_ was simplified for the sake of the demonstration, from a more complicated algorithm.
--
___
See some cool custom tags here:
http://www.contentbox.com/claude/customtags/tagstore.cfm
Please
you cast as late as possible
Exact, but whenever you cast, you cast to the type inplied by the operator, or the type expected by a function in a parameter.
You NEVER cast the operator to fit one of the operands, which apparently was done here.
--
___
See some
Try
#1 or true#
That should return 1, not true.
No, the operator is boolean, it then should return true.
Someone pointed out that the value returned is the last value evaluated.
In (true or 1) that is true, since it's shortcircuited.
Right, the evaluation of true OR true is shortcircuited, but
Darn. I thought I had it.
Thanks for correcting that one.
Jerry Johnson
[EMAIL PROTECTED] 04/20/04 04:44PM
It looks like the operator decides the type for the result for
everything except the AND operator.
Even OR works as you say it should.
#1 + true# 2
#true + 1# 2
#1 and
I'm not a Java programmer, but I would hypothesize that the casting is
done to the operand, but within the and operator.Therefore it is
transparent to the user.
--Ben Doom
Claude Schneegans wrote:
you cast as late as possible
Exact, but whenever you cast, you cast to the type inplied by
in the _expression_ never changes, it is only temporarily coerced as
needed to evaluate the _expression_.
Cheers,
barneyb
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 1:52 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug
Agreed but it returns 20 and not true.
Dave Carabetta wrote:
However, to Johnny Le's original question (at least, as I understood it),
the fact that it evaluates to a true condition (even if it's 20) is *not* a
bug.
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
but I would hypothesize that the casting is done to the operand
Actually, this is not really casting here.
Casting was introduced in the C language.
It means changing the type of a variable, in order to make types compatible or as expected, but it DOES not convert the content of the variable.
The cast is implicit, so it only happens for the evaluation.
Where does this rule come from?
This could be true for a cast, but it is not even a cast in the occurrence: it is a forced conversion.
Don't forget: a cast is performed during compile, a conversion during execution.
Here the problem is
careful and understand what's happening, it's a great
benefit.
Cheers,
barneyb
-Original Message-
From: Bryan F. Hogan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 3:34 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Agreed but it returns 20 and not true.
Dave
does that as an
extra internal step in the evaluation of the _expression_.
Cheers,
barneyb
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 2:40 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
The cast is implicit, so it only
Something got lost here, I agree 20 is true, that's why I think #(true
and 20)# should return true and not the numeric value of 20.
Barney Boisvert wrote:
In a loosely typed language (which CF is), 20 IS true.There is NO
DIFFERENCE.
The implementation (which happens in java, a strongly
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
Something got lost here, I agree 20 is true, that's why I
think #(true
and 20)# should return true and not the numeric value of 20.
Barney Boisvert wrote:
In a loosely typed language (which CF is), 20 IS true.There is NO
DIFFERENCE
In a loosely typed language (which CF is), 20 IS true.There is NO
DIFFERENCE.
A loosely typed laguages means that values may be automatically converted as needed, it does not mean that they all are the same. 20 is NOT true: 20 is converted to true if one looks at it as a boolean value.
by CF has
,
barneyb
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 3:35 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
In a loosely typed language (which CF is), 20 IS true.There is NO
DIFFERENCE.
A loosely typed laguages means
how can you argue that 20 is not a valid result from a
boolean _expression_?
Take this code:
CFSET a = 20
CFIF aa is trueCFELSEa is not true/CFIFBR
CFIF a EQ yesa is trueCFELSEa is not true/CFIFBR
CFIF a EQ truea is trueCFELSEa is not true/CFIFBR
CFIF a IS truea is trueCFELSEa is not true/CFIFBR
, April 20, 2004 4:13 PM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
how can you argue that 20 is not a valid result from a
boolean _expression_?
Take this code:
CFSET a = 20
CFIF aa is trueCFELSEa is not true/CFIFBR
CFIF a EQ yesa is trueCFELSEa is not true/CFIFBR
CFIF a EQ truea
: Wednesday, 21 April 2004 9:13 AM
To: CF-Talk
Subject: Re: Is it a bug or not a bug?
how can you argue that 20 is not a valid result from a
boolean _expression_?
Take this code:
CFSET a = 20
CFIF aa is trueCFELSEa is not true/CFIFBR
CFIF a EQ yesa is trueCFELSEa is not true/CFIFBR
CFIF a EQ truea
Why should 'a' (a number) be treated as equal to the boolean true, if it's
not treated as equal to the string 'yes',
... hmmm well, may be for the same reason the _expression_ (true AND 4*5) is evaluated to 20 although it should have a boolean value ;-))
--
Aside from that
error, my statement is correct.
Ok, but temporarily or not, it IS converted, then 4*5 should be converted to true first. Thus the _expression_ should never return 20, the value 20 does not exist anymore.
In the _expression_ (true AND 4*5). the only way it can be evaluated, and the
So all those people using cfif Len(Trim(value))IS TRUEcfelseIS FALSE/cfif are doing it wrong? I dont think so... this is valid and good practice.
Please don't mix up everything: it IS correct to use your statement, because len(...) will be converted to a boolean.
You can use any integer in a
63 matches
Mail list logo
