Provide namespace for exports

IBM does not intend to provide a solution to this request at this time, so it is being closed.

However, there is another RFE 92592 with a somewhat-similar requirement for a namespace feature within a single ILE RPG module. That RFE has been accepted. The title of the RFE is "Prefix or Qualified Keyword for Exports and/or Prototypes".
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92592

The CAAC has reviewed this requirement and recommends that IBM view this as a high priority requirement that should be addressed.

Ending for every comment:
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Dawn May - CAAC Program Manager

IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.

A potential syntax could be something like:
dcl-ns code Srvpgm([library/]name) Prototypes([library/]name);

It could also be namespaced on the /copy directive to namespace any declarations:
/copy [library/][sourcefile,]member namespace

A procedure name would then be something like:
[code::]procedureName(...);

Then you could write

dcl-ns rm rpgmap/rmsrvpgm;

rm::map(...);

Or for those who want a longer namespace:

dcl-ns RPGMap rpgmap/rmsrvpgm;

RPGMap::map(...);

RDi code completion routines could then recognize namespaces defined in a source and offer to complete them with :: and then include a list of available procedures in the namespace. The outline could even group prototypes by namespace. If using /copy directive, it would have to be determined how the namespace of nested /copy declarations would be affected.

I would like to add some suggestions for this:

Enhance the Binder Language as follows:

1. on the STRPGMEXP command, add a new PREFIX keyword that would allow for either PREFIX(*MODULE) or PREFIX(*SRVPGM) or both. This would concatenate the name of the *MODULE or *SRVPGM to the start of each exported procdure name or data element name,.

For examople, from CGUDEV2, if I specified:

STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*SRVPGM)

This would result in procedure names such as:

CGISRVPGM2_ADDMSG
CGISRVPGM2_CFGMSGS
etc.

If I specified:

STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*MODULE)

This would result in procedure names such as:

XXXUSRSPC_CRTUSRSPC
XXXUSRSPC_RTVUSRSPCPTR

and if I specify:

STRPGMEXP PGMLVL(*CURRRENT) PREFIX(*MODULE *SRVPGM)

This would result in procedure names such as:

CGISRVPGM2_ XXXUSRSPC_CRTUSRSPC
CGISRVPGM2_ XXXUSRSPC_RTVUSRSPCPTR

where the hierarchy would always be: service program name first, then module name, then procedure or data element name.



Also, for further flexibility, the binder source EXPORT command should be expanded with a new keyword, for example "AS" to work as follows:

EXPORT SYMBOL(ISDEBUG) AS(MY_ASDEBUG)
or
EXPORT SYMBOL(DOCMD) AS(COMMANDS_DOCMD)

This would give the developer total control over the names exported from any given version of any service program created.

If I can assign a namespace to v1 of a service program, and a different namespace to v2 of the same service program that lives in a different location, then namespaces can be used to solve the problems I am seeing. Your method of resolving to service programs with incompatible exports will also work, but there is no guarantee that the developer of v2 will change the signature. In any case, a new namespace would solve the problem. Namespaces would have to be able to fully qualify an export by service program and library for this to work.

If I can assign a namespace to v1 of a service program, and a different namespace to v2 of the same service program that lives in a different location, then namespaces can be used to solve the problems I am seeing. Your method of resolving to service programs with incompatible exports will also work, but there is no guarantee that the developer of v2 will change the signature. In any case, a new namespace would solve the problem. Namespaces would have to be able to fully qualify an export by service program and library for this to work.

I would also like to have namespaces for procedures (or rather all exported symbols) but the problem you are describing is not really related to namespaces but rather to different versions of the same serviceprogram. Using binder language and giving the service program the correct signatures could help here (or be at least 50% of the solution).

Lets assume we have service program binarytree in version 1.2 with the signatures "bintree1.2", "bintree1.1" and "bintree1.0" (as version 1.2 is compatible with 1.1 and 1.0) and the same service program but with some incompatible exports and thus removing all previous signatures and giving it the signature "bintree2.0".

Now if both service programs are in the library list the bound program should take the appropriate service program with the correct signature and not fail on the first one because of the right name but the wrong signature (don't know if that is the case atm).