× 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.



As far as numeric fields, yes, it could be transparent... but I guess I was thinking more of the bigger picture. For alpha fields, I frequently pass more data than the length of the field on the prototype, and I've run into several others who do the same thing.

My concern is that the RPG compiler would see that my field size doesn't match, and go through a temporary intermediary -- which would cause the data to get chopped off.

But as I'm thinking about this a little more, I'm not sure that would really be an issue. I probably spoke too soon.


Simon Coulter wrote:
On 14/01/2010, at 7:16 AM, Scott Klement wrote:

Obviously there'd have to be SOME SORT of keyword on the prototype
itself, otherwise you'd break backward compatibility. But I don't think
she was suggesting that it require you to specify the from/to variable
types.

Really? Seems to me that this could/should be transparent. It will only work if neither CONST nor VALUE are specified. Existing code therefore must have matching data types for pass-by-reference else they would have received a compile-time error due to the data type not matching the prototype. New code, or newly compiled old code, will either continue to have matching data types or the compiler will build suitable temporary variables.

I think the only issues are:
1) Conversion happens only on the call therefore the PI must match the PR (as it does currently).

2) Conversion must be compatible without loss of scale or precision (therefore INTs can be promoted to decimal but not the reverse unless dec-pos is zero, decimals can only be promoted to another decimal with same or greater scale or precision, etc.)

This way the change would be completely transparent. The only noticeable change will be that the compiler will no longer complain about mismatched data types on the call as long as the data types are compatible. Backwards compatibility stays intact because the behaviour at run-time is still the same. If the caller provided matching data types then behaviour is identical. If the caller provided compatible data types then behaviour appears identical (i.e., correct result with no loss of scale or precision).

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.