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



PHP has a similar feature. In order to use variables from the global scope inside a function, that variable must be either defined as global in the function, or the code must explicitly state that this use of the variable is coming from the global scope. I like that because you can't inadvertently affect other functions by changing the global scope. You must be intentional about it, and advertise it to the rest of the world. Maybe a keyword on the dcl-s or dcl-ds statement would work:

dcl-s a Int(10) Inz(5);

dcl-proc localProc;
dcl-pi *n Int(10) end-pi;

dcl-s a Global;
dcl-s b Int(10) Inz(10);

b = a + b;

return b;
end-proc;

A call to localProc would return 15.

I don't know if I like the idea of declaring which fields would be available by default in all procedures in the ctl-opt because then I don't really know by looking at the procedure which fields are available from the global scope. It might be less coding, but so were the use of conditioning indicators, and I stopped using them in fixed form code in favor of if - endif even with simple yes/no tests, just for readability. I do agree with a ctl-opt that specifies *ALL or *NONE with a default of *ALL. Declarations with the Global keyword would be ignored in the case of *ALL. Maybe the ctl-opt keyword could be something like ExplicitGlobals or NoExplicitGlobals. One issue I would have with Global(field1) making global scope field1 available in all procedures, is how do you turn that off if you don't want it? Maybe the same way as now, by explicitly declaring the variable again in the local scope, but doesn't that get you right back to at least some of the confusion you had teaching globals and local scope before?

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote: -----
To: Rpg400 Rpg400-L <rpg400-l@xxxxxxxxxxxx>
From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
Date: 11/11/2016 06:12PM
Subject: New RFE for RPG


This is something I have wanted for a very long time - the ability to restrict access to global variables from within subprocedures. Trying to teach folks how to use subprocs and the basics of good modular design is often complicated that they reference globals in error and of course the compiler accepts it.

If you think this would be a good idea please vote for it here: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97164 <http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97164>


Jon Paris

www.partner400.com
www.SystemiDeveloper.com


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.