Re: 7.1 and RPG prototypes

OK - I see where you are coming from - but, as you seem to realize, what you would like is hardly a practical option.

What would be required to enable the "PI rules" philosophy is a system wide extension that captures the full details of the parameters and return value. Right now the closest we have to that is PCML and that has multiple problems including an inability to be able to represent a number of parameter types. Even if that problem were addressed (not likely worth IBM's investment) then there is still the problem of late binding. For instance a dynamically called program can be subject to library list and other factors - how can the compiler validate against something that may not even exist at compile time. Same problem with Service Program procedures that are dynamically bound - or bound via procedure pointer.

I am interested in minimizing problems with what we have and asking for extensions (such as the RFE in question) that help to avoid errors. I think we have more chance of IBM i being open sourced than seeing the types of changes needed to avoid protos altogether.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 4, 2018, at 6:38 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

On Sun, Mar 4, 2018 at 4:34 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

That was the point I made John - in the very first sentence of my post (i.e. not the bit you copied).

No, I caught that part. What I was having trouble understanding was
how forcing the prototype to exist (separate from the interface) for
exported procedures helps.

What I think it comes down to is that the whole /COPY mechanism
doesn't sit well with me. It feels like a kludge. It "works" to the
extent that it's a well-known and officially endorsed convention. Most
places that use it effectively have a combination of tools and shop
standards which encourage it. To me, those tools and shop standards
*are* the validation mechanism (given that RPG is what it is).

What the RFE proposes is a kind of indirect support for the convention
you describe as

The "same code" would not be in the same source [...]. The prototypes would be in a separate source and /COPY'd into BOTH the defining and using source files.

Conceptually, how /COPY works is that *to the compiler*, the same code
*IS* in the same source. The compiler doesn't care whether you use
/COPY or you use CC..CC in SEU and change all the PI to PR in the
copied lines, does it? As far as I know, all it is *enforcing* is that
the same boilerplate shows up twice.

In fact, I think I would be happier if the compiler could somehow
*enforce* that you ***DO*** use /COPY, and not just copy-and-paste.

Because that would get it closer to having an actual, proper import mechanism.

Let me pose the question in reverse.

Given that your prototypes are in source file X - how would you ensure that they are an _accurate_ representation of the PI?

I don't accept your premise. How *I* would ensure that the
"prototypes" are an accurate representation of the interfaces is to
not have separate prototypes and interfaces.

What I will acknowledge is that a proper import mechanism is likely to
be a lot of work to implement, including a lot of thinking about how
to even go about it. And I will acknowledge that having the compiler
"encourage" the /COPY convention in the manner proposed by the RFE is
likely to have a measurable, real-world benefit for relatively little
difficulty in implementation.

John Y.
--
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: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
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: http://amzn.to/2dEadiD