Clipper - Subtleties of iif() Re: Tbrowse question

Author

Subtleties of iif() Re: Tbrowse question

diogenes

2006-09-02, 3:55 am

Stephen Quinn wrote:
> ehab
>
> Sorry missed one<g>
>
> y := IIF( x = 1, 4, IIF( x = 2, 5, IIF( x = 3, 6, 0 )))
>
> HTH
> Steve

Indeed, I use code blocks EXTENSIVELY in my work, where
if...else...endif can't be used, so I've become a real pro at using the
if(...) or iif(...) function in this way. Some elaboration might be of
interest.

The first conditional value can be another nested iif too. Thus, you
can make constructs like:
if ( x = 1 )
if ( y = 10 )
whatever-1
else
whatever-2
endif
else
if ( y = 20 )
whatever-3
else
whatever-4
endif
endif

like this:

iif ( x = 1, iif ( y = 10, what-1, what-2 ), iif ( y = 20,
what-3, what-4 ) )

and where any of these iif()'s can be nested arbitrarily deeply to
create all the elseif's you could ever hope to parse. (within limits.
.. . )

Now, here's a subtle and important fact about iif(...) that I've NEVER
SEEN MENTIONED IN ANY documentation anywhere, yet I'm sure we use this
fact all the time, perhaps without even realizing it:

***** IIF( ) IS NOT A TRUE FUNCTION! *****

When a function is called, all its arguments are evaluated and the
resulting values are passed to the function. Everybody knows this.
But this does NOT happen when calling the iif(...) "function".
Instead, this happens: The first argument (the condition) is
evaluated. Then, according to the result, one or the other of the
other arguments is evaluated. Note well: ONLY the selected one of
those arguments is evaluated! This behavior is not at all like
"normal" functions!

This is important when the expressions b and c in iif( L, b, c )
contain side-effects! If all arguments were evaluated, then the side
effects of BOTH b and c would happen no matter which of b or c was
selected by L. But this does not happen! Only the side effects of the
selected expression happen.

Case in point: The original example if the iif(...) at the beginning
of this thread had expressions that assigned new values to fields.
Certainly, you want ONLY the selected assignment to happen, not both of
them.

This is subtle, important, and as I noted, UNDOCUMENTED as far as I
know. How many Clipper programmers have noticed this? And how many
have depended on this fact without even realizing it?

Note, this is very different behavior from the IIF() and Choose( )
functions in Visual Basic, where ALL the arguments are evaluated and
ALL their side-effects happen even though only one is returned (and
which is clearly stated in the Visual Basic reference manuals).

-- diogenes
(Jay Jaeckel)
--------------------------------------------

news@dizbiz.co.uk

2006-09-03, 3:55 am

In article <1157181026.767488.274750@p79g2000cwp.googlegroups.com>
jjaeckel@gmail.com "diogenes" writes:

> Stephen Quinn wrote:
>
> Indeed, I use code blocks EXTENSIVELY in my work, where
> if...else...endif can't be used, so I've become a real pro at using the
> if(...) or iif(...) function in this way. Some elaboration might be of
> interest.

[snip]

> Now, here's a subtle and important fact about iif(...) that I've NEVER
> SEEN MENTIONED IN ANY documentation anywhere, yet I'm sure we use this
> fact all the time, perhaps without even realizing it:
>
> ***** IIF( ) IS NOT A TRUE FUNCTION! *****

The thought that it ever _was_ a function never crossed my mind.
I came to Clipper from C and was familiar with the latter's '?'
operator:

result = <expression> ? <expression_if_true>
: <expression_if_false> ;

and knowing that Clipper was written [mainly] in C, I assumed
that IIF() just mapped onto that...

> When a function is called, all its arguments are evaluated and the
> resulting values are passed to the function. Everybody knows this.
> But this does NOT happen when calling the iif(...) "function".
> Instead, this happens: The first argument (the condition) is
> evaluated. Then, according to the result, one or the other of the
> other arguments is evaluated. Note well: ONLY the selected one of
> those arguments is evaluated! This behavior is not at all like
> "normal" functions!

This is what the [S87] documentation says:

| IIF(<expL>, <exp1>, <exp2> )
|
| Note that unlike other dialects, <exp1> and <exp2> can
| evaluate to different data types. Note also that only the
| expression selected by the result of <expL> is evaluated.
| This means that an undefined or erroneous argument for the
| non-executed expression does not generate a runtime error.

I'd be surprised if the 5.x doc didn't say something similar,
given of course that both versions of IIF() behave identically
(which I would expect for backward compatibility).

Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."

Sponsored Links