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



Thanks for the comment Mark but could you - or anyone else with suggestions - please put them into the comments section of the RFE. _That’s_ the stuff that IBM will pay attention to.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Nov 14, 2016, at 10:26 AM, Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx> wrote:

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 teachi
ng 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

--
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: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.