Re: Latest RPG Updates

The procedures would normally have their own protos - although if they are internal the procedure interface is enough.

The procedures/programs are independently callable things that require their own protos anyway.

You don't like it - fine. But for me it needed to be an evbolutionary step from what we have. It needed to be simple. It needed to make sense.

In my opinion it meets all of those objectives.

On Oct 8, 2019, at 12:43 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

On Tue, Oct 8, 2019 at 3:10 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Because the return type/size has to be the same on _all_candidates. So I guess this is just defined as a baseline to make it obvious to anyone studying the proto that no matter what routine does the work, a VarChar(100) will be returned.

Then we're back to "double up on the prototypes, no matter what".

If it must be the same on all candidates, then either

(1) define the return value just on FORMAT (define it once, the
compiler propagates it to the rest), or

(2) define the return value just on each of FORMAT_* (define it three
times, the compiler checks that they are all the same, and propagates
it to FORMAT).

The first option is the least repetitive and least error-prone.

Any arguments along the lines of "but I want to be able to read it and
know what everything is without jumping around" undermine the D-spec
concept and in effect argue for going back to in-line definitions, or
even worse, argue for *more* copy-pasting.

There is a reason why most languages strive to reduce the repetition
to a minimum. RPG seems to have the pattern of "whoa, that's too hard
to figure out how to implement, let's make the programmer type extra
(or copy-paste!) to make things simpler for us compiler writers".
Maybe this is sold under the guise of providing "extra checking" but
really it's pointless extra hoops. As with the pointlessly duplicated
prototypes for same-module procedures, eventually they will realize
that they can implement it after all.

I can tell that some folks would rather the compiler team just hunker
down and take extra time if needed to figure it all out and get it
right the first time. An RFC period (proposed by someone else) would
actually be a great boon for this. I mean, sometimes the commenters
simply don't have enough information about the true difficulty of
implementing something. It will always be the implementers'
prerogative to reject all comments. But for the cases where the
commenters have a point, the RFC process would help reduce the chance
that good ideas are missed.

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com