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



Sorry - meant to comment on this bit ...

<snip>
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.
</snip>

What the compiler "sees" is effectively a single source - Yes. And I would be OK with a rule that says you MUST use /COPY (/INCLUDE) for prototypes. That does at least help to guarantee that there is only one place where they are coded.

What I don't understand is how you propose that the _using_ routine be informed of the interface requirements. If not via a prototype (and accepting that a system wide facility has too high a cost and too many issues) then how do you propose it could work?


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


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.