Topic
  • 4 replies
  • Latest Post - ‏2014-08-18T21:44:35Z by barbara_morris
Parkib
Parkib
3 Posts

Pinned topic Omitting prototypes

‏2014-08-17T17:23:06Z |

Amongst the enhancements in 7.1 was the following:

Optional prototypes
If a program or procedure is not called by another RPG module, it is optional to specify the
prototype. The prototype may be omitted for the following types of programs and procedures:
v A program that is only intended to be used as an exit program or as the command-processing
program for a command
v A program that is only intended to be called from a different programming language
v A procedure that is not exported from the module
v A procedure that is exported from the module but only intended to be called from a different
programming language

Because of the conditions listed, I had not given this enhancement much thought - until now. Recently, I tried out a few examples of normal RPGIV-to-RPGIV calls with the above enhancement in mind.

My experiments revealed that for both program and procedure calls, the Prototype in not required within the Called routine, even when performing a normal RPGIV-to-RPGIV call. I confess I do like not having to replicate the Prototype in the Called code. (Not least because it makes it easier to explain to RPG novices.)

My qustion is this. Am I doing anything that I really should not? In other words, have I found a "loop hole" which may affect my code in the future?

Let me make it clear that I understand the benefits of including the Prototype in the Called program/procedure. However, is this a NECESSITY for normal inter-program calls which do not meet the conditions listed above?

  • JonParis
    JonParis
    117 Posts
    ACCEPTED ANSWER

    Re: Omitting prototypes

    ‏2014-08-17T18:31:54Z  

    Not a loophole - more the inevitable result of relaxing the rules.

    I suspect that the manual spells it out in terms of the way that they _hope_ people will use the new support. i.e. only omitting the prototype when A) a non RPG language is involved or B) Calling local subprocedures - which is the only time I really take advantage of it.

    If you think about it, it has to be this way. The compiler can never know what language is calling it until it happens. Even then, although to a degree it could find out, it doesn't because it doesn't care. Since it cannot be determined at compile time they either have to enforce it or not on a global level - they have chosen not to.

    It does make it harder to convince people that prototypes should only ever be /COPY'd in and never be hardcoded but that was the price of admission for making them optional.

     

    On the whole the trade-off is worth it but ...

    Updated on 2014-08-17T18:33:05Z at 2014-08-17T18:33:05Z by JonParis
  • barbara_morris
    barbara_morris
    389 Posts
    ACCEPTED ANSWER

    Re: Omitting prototypes

    ‏2014-08-18T18:14:34Z  
    • JonParis
    • ‏2014-08-17T18:31:54Z

    Not a loophole - more the inevitable result of relaxing the rules.

    I suspect that the manual spells it out in terms of the way that they _hope_ people will use the new support. i.e. only omitting the prototype when A) a non RPG language is involved or B) Calling local subprocedures - which is the only time I really take advantage of it.

    If you think about it, it has to be this way. The compiler can never know what language is calling it until it happens. Even then, although to a degree it could find out, it doesn't because it doesn't care. Since it cannot be determined at compile time they either have to enforce it or not on a global level - they have chosen not to.

    It does make it harder to convince people that prototypes should only ever be /COPY'd in and never be hardcoded but that was the price of admission for making them optional.

     

    On the whole the trade-off is worth it but ...

    Jon is right that the compiler can't enforce the "rule". (He's also right that those rules about when to omit the prototype are just what we _hope_ people will follow.)

    Brian, I really think it's worth the difficulty of explaining prototypes to novices. I think the new rules should make it somewhat simpler to introduce prototypes, especially if you simplify the rules to say

    • All exported procedures need a prototype in a /copy file
    • All programs need a prototype in a copy file

    I remember learning Fortran, and the teacher said it was necessary to code "IMPLICIT NONE" in every source file. He didn't say why, he just said we had to do it. Much later, we learned that it wasn't actually necessary, but that if we didn't code it, the Fortran compiler would implicitly define variables with the implicit type depending on the first letter of the name. For novice RPG programmers, the necessity to code prototypes in the called module seems similar: a seemingly arbitrary rule that prevents the compiler from doing something unwise.

    I really do think it is unwise not to copy the prototype into the called module; if only the callers have the prototype, then you can change the prototype and recompile the called procedure and the compiler won't complain, which basically puts you back in the world of the *ENTRY PLIST where parameter mismatches were a very common problem.

    I think that having a copy file with prototypes has to be considered a normal part of coding RPG.

  • JonParis
    JonParis
    117 Posts

    Re: Omitting prototypes

    ‏2014-08-17T18:31:54Z  

    Not a loophole - more the inevitable result of relaxing the rules.

    I suspect that the manual spells it out in terms of the way that they _hope_ people will use the new support. i.e. only omitting the prototype when A) a non RPG language is involved or B) Calling local subprocedures - which is the only time I really take advantage of it.

    If you think about it, it has to be this way. The compiler can never know what language is calling it until it happens. Even then, although to a degree it could find out, it doesn't because it doesn't care. Since it cannot be determined at compile time they either have to enforce it or not on a global level - they have chosen not to.

    It does make it harder to convince people that prototypes should only ever be /COPY'd in and never be hardcoded but that was the price of admission for making them optional.

     

    On the whole the trade-off is worth it but ...

    Updated on 2014-08-17T18:33:05Z at 2014-08-17T18:33:05Z by JonParis
  • barbara_morris
    barbara_morris
    389 Posts

    Re: Omitting prototypes

    ‏2014-08-18T18:14:34Z  
    • JonParis
    • ‏2014-08-17T18:31:54Z

    Not a loophole - more the inevitable result of relaxing the rules.

    I suspect that the manual spells it out in terms of the way that they _hope_ people will use the new support. i.e. only omitting the prototype when A) a non RPG language is involved or B) Calling local subprocedures - which is the only time I really take advantage of it.

    If you think about it, it has to be this way. The compiler can never know what language is calling it until it happens. Even then, although to a degree it could find out, it doesn't because it doesn't care. Since it cannot be determined at compile time they either have to enforce it or not on a global level - they have chosen not to.

    It does make it harder to convince people that prototypes should only ever be /COPY'd in and never be hardcoded but that was the price of admission for making them optional.

     

    On the whole the trade-off is worth it but ...

    Jon is right that the compiler can't enforce the "rule". (He's also right that those rules about when to omit the prototype are just what we _hope_ people will follow.)

    Brian, I really think it's worth the difficulty of explaining prototypes to novices. I think the new rules should make it somewhat simpler to introduce prototypes, especially if you simplify the rules to say

    • All exported procedures need a prototype in a /copy file
    • All programs need a prototype in a copy file

    I remember learning Fortran, and the teacher said it was necessary to code "IMPLICIT NONE" in every source file. He didn't say why, he just said we had to do it. Much later, we learned that it wasn't actually necessary, but that if we didn't code it, the Fortran compiler would implicitly define variables with the implicit type depending on the first letter of the name. For novice RPG programmers, the necessity to code prototypes in the called module seems similar: a seemingly arbitrary rule that prevents the compiler from doing something unwise.

    I really do think it is unwise not to copy the prototype into the called module; if only the callers have the prototype, then you can change the prototype and recompile the called procedure and the compiler won't complain, which basically puts you back in the world of the *ENTRY PLIST where parameter mismatches were a very common problem.

    I think that having a copy file with prototypes has to be considered a normal part of coding RPG.

  • Parkib
    Parkib
    3 Posts

    Re: Omitting prototypes

    ‏2014-08-18T20:13:37Z  

    Jon and Barbara, thank you for your responses. Very helpful and very much appreciated.

    I completely agree with the wisdom of placing the Prototype in both Caller and Called programs/procedures. This will be encouraged, along with using /COPY (or /INCLUDE) for the Prototype source.

    Since subprocedures and prototypes were first introduced I have struggled to convey the benefits to an audience brought up on *ENTRY PLIST coding. Duplicating the prototype code - despite the benefits - is not always well received. I have come across some shops that expressly forbid the use of /COPY. This complicates matters.

    With the recent enhancements, I now have a way of introducing the concept of prototyped calls without the hurdle of duplicated code at the get-go. Rest assured that by the end of  the presentation, the merits of Prototypes in Caller and Caled units using copybooks will be fully explored.. (Barbara, if I may I would like to plagiarise your wording from the 2012 presentation, "What's new for RPG in 7.1".)

    Thank you both again for your insight.

  • barbara_morris
    barbara_morris
    389 Posts

    Re: Omitting prototypes

    ‏2014-08-18T21:44:35Z  
    • Parkib
    • ‏2014-08-18T20:13:37Z

    Jon and Barbara, thank you for your responses. Very helpful and very much appreciated.

    I completely agree with the wisdom of placing the Prototype in both Caller and Called programs/procedures. This will be encouraged, along with using /COPY (or /INCLUDE) for the Prototype source.

    Since subprocedures and prototypes were first introduced I have struggled to convey the benefits to an audience brought up on *ENTRY PLIST coding. Duplicating the prototype code - despite the benefits - is not always well received. I have come across some shops that expressly forbid the use of /COPY. This complicates matters.

    With the recent enhancements, I now have a way of introducing the concept of prototyped calls without the hurdle of duplicated code at the get-go. Rest assured that by the end of  the presentation, the merits of Prototypes in Caller and Caled units using copybooks will be fully explored.. (Barbara, if I may I would like to plagiarise your wording from the 2012 presentation, "What's new for RPG in 7.1".)

    Thank you both again for your insight.

    Yes, please feel free to use the wording from the presentation. :-)