Evaluation of logical expressions in VO 2.7
Terje Barman
How does VO 2.7 deal with logical statements such as
IF lTrueVal .And. lFalseVal .And. lTrueVal2
// do this
ELSE
// do that
ENDIF
Will it stop after it has evaluated lFalseVal and skip lTrueVal2? This is
btw the behavour of VO 2.5. Or will it go on and evaluate lTrueVal2 as well,
which is the behaviour og VO 2.6.
IMHO that it should stick to the VO 2.5 strategy since we then don't need to
nest statements like
IF oLVI!=NULL_OBJECT .And. oLVI:Value=5333
// do this
ENDIF
into
IF oLVI!=NULL_OBJECT
IF oLVI:Value=5333
// now do this
ENDIF
ENDIF
Have a nice weekend!
Terje
Jari Sevon
> How does VO 2.7 deal with logical statements such as
> IF lTrueVal .And. lFalseVal .And. lTrueVal2
> // do this
> ELSE
> // do that
> ENDIF
> Will it stop after it has evaluated lFalseVal and skip lTrueVal2? This is
> btw the behavour of VO 2.5. Or will it go on and evaluate lTrueVal2 as
well,
> which is the behaviour og VO 2.6.
I think this has been configurable in 2.5. I am not 100% sure, but I
remember
something like this.
Haven't used 2.6, but could it be that default value has been changed?
- Jari -
Geoff Schaller
Not sure what you are on about. I can't answer for 2.7 (not sure anyone here
can <g>) but this behaviour is the same in 2.5 and in 2.6 - perhaps you just
have your optimisation settings different.
Geoff
PS... you shouldn't be writing logic statments like this anyway...
"Terje Barman" <te...@barman-hanssen.no> wrote in message
news:3yyab.31178$Hb.4...@news4.e.nsc.no...
Phil McGuinness
> > IF lTrueVal .And. lFalseVal .And. lTrueVal2 ]
Why would they change it.... ?
It has been the same in Clipper / VO1 / Vo2 / Vo2.5 / Vo2.6.
I cannot understand why it would different in VO2.7 and if it was it would
break and enormous amount of code.
I think you can sleep easy on that one.
snip[> PS... you shouldn't be writing logic statments like this anyway... ]
Crap.. and great language like VO allows you to have logical conditions in
line and based on their results and .AND. / .OR. conditions you can build up
some very logical structures.
IF oServer:Used .AND. oServer:SEEK(xxx)
As you can see you would not want to be SEEKING on and a server that is not
opened and without having to ENDIF condtions you can do it one like. THis
is just and example of course but should work fine ... and it does.
Phil McGuinness - Sherlock Software
----------
"Geoff Schaller" <geo...@softwareXXobjectives.com.au> wrote in message
news:aeBab.111573$bo1.1...@news-server.bigpond.net.au...
Geoff Schaller
Don't attack me, I said the same as you.
> IF oServer:Used .AND. oServer:SEEK(xxx)
I'm quite happy with this but again, its coding style and future
maintainability. When you are certain of compiler switch settings and your
own understanding, it works fine but the following is arguably always
better:
IF oServer:Used
IF oServer:SEEK(xxx)
....
ENDIF
ENDIF
This is the most ideal construct because its clear - both from a precedence
and visual management perspective. Although this is a trivial example, the
habit is bad because you start coding 2, 3, or more conditions into a
statement and suddenly it gets harder and harder to read and maintain (or
even follow the logical thread). I'm not saying that you can't or shouldn't
do this but I am saying its better code. There is another reason. The first
way only allows one failure branch (ie two conditions tested - one response
possible). The second way allows you to properly identify both causes for
failure and thus you can deal with them separately. As I say, better code.
So in the end, if you code the second way you CAN'T get a problem even if
your compiler settings are wrong <g>.
Geoff
Jack
Just an statement (it won't help you in anyway).
I remember from my turbo pascal years (many light year ago in a galaxy far,
far away) that it had a compiler switch named something like "complete
boolean evaluation" just to deal with this topic.
I agree with Geoff that :
if l_val1
if l_val2
.....
is good readable code.
Jack
"Terje Barman" <te...@barman-hanssen.no> wrote in message
news:3yyab.31178$Hb.4...@news4.e.nsc.no...
Malcolm Gray
I think the second is harder to maintain as soon as an else cause
appears.
One common test we use after (our few) softseek is
if !oserver:EOF .and. oServer:Fieldget(#field)==...
//something foundcase
else
//nothing found case
endif
in that case there is only one error case, you just have to do two
checks to detect it.
Luis Garcia
Malcolm Gray wrote:
> Geoff Schaller wrote:
>
>>
>>IF oServer:Used
>> IF oServer:SEEK(xxx)
>> ....
>> ENDIF
>>ENDIF
>>
>
> I think the second is harder to maintain as soon as an else cause
> appears.
> One common test we use after (our few) softseek is
> if !oserver:EOF .and. oServer:Fieldget(#field)==...
> //something foundcase
> else
> //nothing found case
> endif
> in that case there is only one error case, you just have to do two
> checks to detect it.
>
mmmm many stylecoding here, interesting, what about....
if !osErver:used
.....//some stuff
return nil
endif
//from here do whatever you want with the server
..
.
.
Regards
Luis MX
Malcolm Gray
> mmmm many stylecoding here, interesting, what about....
>
> if !osErver:used
> .....//some stuff
> return nil
> endif
would normally fail code review here on the basis of having more
than one exit from the function.
Jari Sevon
> PS... you shouldn't be writing logic statments like this anyway...
I agree with you, it really makes coding more fuzzy.
- Jari -
Geoff Schaller
> if !osErver:used
> .....//some stuff
> return nil
> endif
I agree with Malcom, although I am guilty of this (...as Bruce continually
points out to me <g>), it is very sloppy coding indeed.
Geoff
yves
I hope there is no change ( up the cost of migration to 2.7)
Yves
"Terje Barman" <te...@barman-hanssen.no> a écrit dans le message de news:
3yyab.31178$Hb.4...@news4.e.nsc.no...
Malcolm Gray
>
> How does VO 2.7 deal with logical statements such as
>
> IF lTrueVal .And. lFalseVal .And. lTrueVal2
> // do this
> ELSE
> // do that
> ENDIF
>
> Will it stop after it has evaluated lFalseVal and skip lTrueVal2? This is
> btw the behavour of VO 2.5. Or will it go on and evaluate lTrueVal2 as well,
> which is the behaviour og VO 2.6.
Ok what does 2.6 do?
testing here seems to say that sometimes it shortcircuits and sometimes not?
GLOBAL oCon AS Console
FUNCTION START(p)
oCon := Console{}
IF One() .AND. two()
oCon:WriteLine("One() .AND. TWO() = .T.")
ELSE
oCon:WriteLine("One() .AND. TWO() = .F.")
ENDIF
IF three() .AND. four()
oCon:WriteLine("Three() .AND. four() = .T.")
ELSE
oCon:WriteLine("Three() .AND. Four() = .F.")
ENDIF
oCon:WriteLine("And not in an IF")
oCon:WriteLine("One() .AND. two() " + AsString(One() .AND. two()))
oCon:WriteLine("three() .AND. four() " + AsString(three() .AND. four()))
FUNCTION One() AS LOGIC
oCon:WriteLine("One - returning true")
RETURN TRUE
FUNCTION two() AS LOGIC
oCon:WriteLine("two - returning true")
RETURN TRUE
FUNCTION three() AS LOGIC
oCon:WriteLine("three - returning false")
RETURN FALSE
FUNCTION four() AS LOGIC
oCon:WriteLine("four - returning false")
RETURN FALSE
----------------
Output:
One - returning true
two - returning true
One() .AND. TWO() = .T.
three - returning false
Three() .AND. Four() = .F.
And not in an IF
One - returning true
two - returning true
One() .AND. two() .T.
three - returning false
four - returning false
three() .AND. four() .F.