RE: Hyphenated Op-Codes

["Larry Ducie" <Larry_Ducie@xxxxxxxxxxx>]

Hi Scott,
 
<snip>
The only problem I have with that idea is that it's not a function. That is,
it doesn't return a value! All other BIFs return something, and therefore
they make sense to use in an expression.
</snip>
 
That isn't strictly true:
 
BIFs such as %fields, and %kds can't be used in expressions. They can only
be used when manipulating database file I/O.
 
The BIF %this can't be used in an expression as we know it. It is simply a
reference to the current object, when used in native mathods called from
java. Although it does return an object type I can't imagine it ever being
used in an evaluation expression - it's just used by the JVM to ensure the
correct instance variables are used when calling a java method from within a
RPG native method. You just pass it as the first variable in a method call.

 
Anyway, I get your point. I'm just saying that IBM have already introduced
BIFs that can't be used in evaluation expressions or comparative expressions
so we're already on our way down that road. I'm just suggesting we go
further down that road: I would rather have %evalCorr() than EVAL-CORR. We
could simply have it return a value that can be discarded if required - like
callp. I like the flexibility in that.
 
We could have...
 
if %evalCorr(myFirstDS:mySecondDS) = true; // returns true of at least one
mapping occurs, or if the mapping completes successfully.
 
or...
 
if %evalCorr(myFirstDS:mySecondDS) > *zero; // returns the number of
successful mappings that occur.
 
In either case we would still have the option of...
 
%evalCorr(myFirstDS:mySecondDS); // don't care what it returns, we just want
the side-effects.
 
This way, the BIFs begin to behave in a way that's consistent with all other
functions we use (user-defined or otherwise). Granted, most string
manipulation BIFs would be useless unless they DID return a value. I'm not
suggesting rewriting existing BIFs, I'm simply suggesting that a new op-code
that performs a function, but returns no value should now be implemented as
a BIF which (optionally) returns a completion code of some form. This would
allow us to test it's success easily, or simply discard the result if not
required.  
 
Cheers
 
Larry Ducie