Re: How do you pass an omitted parameter to a procedure? -- RPG400-L

Just one small correction Thomas - I didn't say "ambiguous" (although I guess it is) - I said it was "confusing". I think habituation maybe the reason you have no problem with it. I have never seen it before and viewed it as illegal syntax because the operands were missing from the multiply - it would never have occurred to me that it was equivalent to *Omit.

On 2013-07-05, at 3:29 AM, thomas.raddatz@xxxxxx wrote:

Jon,

Honestly I do not agree with you that the '*' is ambiguous with the
multiply operation. For example:

sendMessage(*: THIS);
sendMessage('Hello': *);
sendMessage(*);
sendMessage();

For me it is ever easier to read than:

sendMessage(*omit: THIS);
sendMessage('Hello': *omit);
sendMessage(*omit);
sendMessage();

But of course that might be just a question of habituation.

In contrast to *omit I completely agree with your opinion about testing
for an omitted parameter. I do not understand why it is so hard for IBM to
enhance the compiler to translate:

if (parmName = *Omit);
or
if (%omitted(parmName));

to
if (%parms() >= n and %addr(parmName) = *null); // V6R1
if (%parms() >= %parmnum(parmName) and %addr(parmName) = *null); //
V7R1

under the cover before compiling the source code. That is nothing more
than a simple pre-compiler task.

Just my two cent.

Regards,

Thomas.

rpg400-l-bounces@xxxxxxxxxxxx schrieb am 04.07.2013 17:53:42:

Von: jon.paris@xxxxxxxxxxxxxx
An: rpg400-l@xxxxxxxxxxxx,
Datum: 04.07.2013 17:54
Betreff: Re: How do you pass an omitted parameter to a procedure?
Gesendet von: rpg400-l-bounces@xxxxxxxxxxxx

Personally I would say this should be flagged as an illegal
operation. I suspect the number of customers affected by any
compiler changes is probably limited to one <grin>

I am amazed that it actually allows this for *Omit and find the *
syntax rather confusing since it looks like a multiply operation
with no operands. Don't think I'd have ever guessed from reading the
code that that was what it was doing.

However - if they do fix the compiler (or even if they don't) I
would really like to see the way *Omit is handled in the receiving
program/procedure get fixed too. It always seems to me you should be
able to say:

If parmName = *Omit; // or *Null for that matter

or even

If %Addr(parmName) = *Omit;

The current requirement that you pass *Omit on the call and then
test for something completely different has always seemed a little
silly to me - but so few people use *Omit at all that there's never
been any real demand for change.

On 2013-07-04, at 6:15 AM, thomas.raddatz@xxxxxx wrote:

This is a survey that I started as a result of an APAR that I opened

at

IBM. The actual problem I have is that RDI 9.0 issues a warning for

the

following statements and therefore does not automatically refresh the
"Outline" view.

sendMessage(*: THIS); // - unexpected token(s) ignored
sendMessage('Hello': *); // - unexpected token(s) ignored
sendMessage(*); // cannot detect whether or not it is
// a procedure call or an indexed array
sendMessage(); // legal statement

Now IBM says that the compiler causes the problem, because actually it

should not accept the '*' as a replacement for '*omit'. Finally they

asked

me whether or not I want to open an APAR to fix the compiler. Since
changing the compiler would cause a lot of work for us I am not sure

what

to do and I like to know whether or not you were affected when IBM

changed

the compiler.

Please select:

[ ] Not affected, let IBM change the compiler

or

[ ] STOP, never change the compiler

Feel free to add additional comments.

Thank you.

Thomas.

--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a

criminal

offence. Please delete if obtained in error and email confirmation

to the sender.

--
This is the RPG programming on the IBM i (AS/400 and iSeries)

(RPG400-L) mailing list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the sender.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com