This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
IBM does not intend to provide a solution to this request at this time, so it is being closed.
While such a feature would be an excellent addition to the RPG language, it is not currently feasible.
Not a lot of languages have nested procedures. I would rather see OO features added to RPG. One language that I remember having nested procedures, though, is PL/1. In addition to nested procedures, PL/1 had recursive procedures, and the ability to set a static label which was resolved the first time the procedure appeared in the stack. Jumping to the static label from a deeply recursed procedure had the effect of returning back to the initial call of the procedure, and clearing the call stack of all the procedure calls in between. Kind of a short cut for ending recursion rather than having to return through all the calls. I don't think I am asking for that. It was a bit to wrap your head around.
We've implemented a list iterator pattern that uses call-back to pass the list item to the operative routine:
iterate( addr_of_operative_procedure, addr_of_comm_area ) ;
...
dcl-proc operative_procedure ; dcl-pi *N ; list_item likeds(item_template) ; comm_area pointer ; end-pi ;
...
The comm_area parameter is used as a way for the operative_procedure to return a result to the caller of iterate(). It is clumsy to code and a little confusing to follow at first. Nested procedure would simplify things nicely, eliminating the need for the comm_area, and making in obvious the intended use of the operative procedure.
It would be super if the nested procedure could be coded in-line:
iterate( op_proc ) ;
dcl-proc op_proc ;
...
end-proc ;
// process opt_proc result
iterate2( op_proc2 ) ;
dcl-proc op_proc2 ;
...
end-proc ;
// and etc.
I don't mind global templates. These aren't global variables, they don't cause sharing issues. They are just standard definitions that can be used to keep things consistent. I like field reference files as well, and they are global. I don't think global definitions are a problem, it is global variables that should be avoided.
@barbara morris: access to the "parent" procedure resources would not necessarily be a good thing. We try to move away from global vars and now introducing something like global vars? That makes it much harder to follow the flow of the program and the scope of its impact (of the procedures). I would down-vote this if I could.
IBM has received the requirement and is evaluating whether it is feasible to implement it. IBM will provide a response after evaluation is complete.
@mihael, with RPG's current procedure mechanism, if a data structure is defined locally in the parent procedure and passed to the other private procedure, the data structure template must be defined globally. With a nested procedure, the data structure template could be private to the two procedures. Similarly with a file defined in the parent procedure and passed to the other procedure; without nested procedures, the file template must be defined globally.
Also, with a nested procedure, the number of parameters could be much smaller since the nested procedure would have direct access to the variables in the parent procedure.
If you don't want to write subroutines (which you are right in not wanting to use) why don't you use private procedures. Just don't export your procedures.
The current state of procedures are totally fine for me.