× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.