I suppose you're right. It's probably an order of operation thing,
where the CF server compiles the variables from the inside out. So
with this:
file="#expandPath("projFiles/#url.jobNum#/#url.fileToOpen#")#"
it would compile in this order:
1. #url.jobNum# & #url.fileToOpen#
2. #expandPath("...")#
Could this be because the internal quotes are part of an evaluated
parameter (i.e.: #expandPath("some#path#")#)?
Cutter
___
http://blog.cutterscrossing.com
Jacob Munson wrote:
> I ran across what I thought was a bug in my code, but it works.
>action="readBinary"
> file="#expand
I ran across what I thought was a bug in my code, but it works.
You'll notice that in the file attribute I've got another quoted value
within the main quotes. When I saw this I thought it was a bug, but
then I remembered that the page hasn't caused me problems before. So
I tried to run it and s
e-
> From: Claude 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...
[To
, 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...
--
___
See some cool custom tags here:
http://www.contentbox.com/c
>>"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]
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
Wednesday, April 21, 2004 11:19 AM
> To: CF-Talk
> Subject: Re: Is it a bug or not a bug?
>
> >>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
a type suitable according to the operators in expressions.
Loosely or not loosely, types do exist.
I agree that in _javascript_ (true && 20) returns 20, like CF, you get a point here.
Now if this is not a bug, this is a severe design flaw.
Take this for instance:
var a = true;
var b = 20;
alert((a
hanging about on my machine, but if anyone else does, I'd be very interested
to see the output from equivalent statements in various other loosely typed
languages.
Cheers,
barneyb
> -Original Message-
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Sent: Tuesd
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]
[T
>>So all those people using IS TRUEIS FALSE 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 boolean _expression_.
What is NOT c
>>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 th
>>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 ;-))
--
_
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:
a is truea is not true
a is truea is not true
a is truea is not true
a is truea is not true
a is falsea is not false
a is falsea i
ginal Message-
> From: Claude Schneegans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 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:
>>how can you argue that 20 is not a valid result from a
boolean _expression_?
Take this code:
a is truea is not true
a is truea is not true
a is truea is not true
a is truea is not true
a is falsea is not false
a is falsea is not false
a is falsea is not false
it shows:
a is true
a is not tru
basis, and then
translated to a yes on a OR gate by the JVM.
Cheers,
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
>>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 C
2004 4:11 PM
> 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 t
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 strongl
: 1
CF does NOT convert the "1" to "true" before evaluating. It 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, 20
However,
as long as your 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
>>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
>> 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.
Y
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]
luation.
The value 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
> Subjec
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 inp
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#
>>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 shortcircu
>>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
>>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 se
"performing mathematical calculations between # signs".
>
>
>
>Mark W. Breneman
>-Cold Fusion Developer
>-Network Administrator
> Vivid Media
> [EMAIL PROTECTED]
> www.vividmedia.com
> 608.270.9770
>
> _
>
>From: Bryan F. Hogan [mailto:[EMA
> >>> [EMAIL PROTECTED] 04/20/04 03:55PM >>>
>
> >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 n
> 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"
>>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 operato
; 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 >>>
>
> >Interesting. I would have guessed that both sets would have
---
> Blog http://www.rewindlife.com
> TeamMM http://www.macromedia.com/go/team
>
>
> > -Original Message-
> > From: Jerry Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 20, 200
>>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
608.270.9770
_
From: Claude 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
> To: CF-Talk
> Subject: Re: Is it a bug or not a bug?
>
> Run this:
>
> truefalse
> truefalse
> truefalse
> truefalse
>
> #true and (4*5)#
> #(4*5) and true#
> #false and (4*5)#
> #(4*5) and false#
>
> Barney Boisvert wrote:
>
> > This i
ct: RE: Is it a bug or not a bug?
>
>
> "and" is a boolean operator. I would expect the result to always be a
> boolean.
>
> In my opinion, it's a bug.
>
> Sam
>
>
>
>
> Blog
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 Unsubsc
>>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
--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 >>>
>
> >Interesting. I would have guessed t
gt;#true and (4*5)#
>#(4*5) and true#
>#false and (4*5)#
>#(4*5) and false#
>
>Barney Boisvert wrote:
>
>> 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
>&
>>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 conv
e?
Why should #1 and 20# automatically output 1?
You are anding a boolean and an integer, and getting an integer out.
I think it would be a bug if it produced different results each time it was called. But it seems to be behaving predictably. Which to me means it is not a bug.
Curious,
Jerry Johnson
>>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]
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
ed the
same exact results. That, to me, is indeed a bug.
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.
Regards,
Dave.
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
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
> >>#(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.
r
-Network 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 g
Run this:
truefalse
truefalse
truefalse
truefalse
#true and (4*5)#
#(4*5) and true#
#false and (4*5)#
#(4*5) and false#
Barney Boisvert wrote:
> 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-circui
>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 Messa
>
>
>Mark W. Breneman
>-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
&g
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',
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. Reg
> >>#(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 e
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
]
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)# returns false.
>#(4*5 and false)# returns false.
>#(4*5 and true)#
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_ evalu
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
>#(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
#(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.
Johnny
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[
CORRECTION!
Check out the documentation for DaysInMonth()...
You have to supply a DATE object, not a numeric month
I fell for that one too!
Norman
-Original Message-
From: Jason Lees (National Express)
[mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 9:14 AM
To: CF-Talk
Subj
68 matches
Mail list logo
