RE: Long Constant Names

Hi,
 
<Barbara said>
If the field really is a constant that will never change even in the
exporter, I don't see the benefit of export/import-const over a copy file
with named constants.
</Barbara said>
 
I don't mind the idea of a globally accessible constant that will never
change (even in the exporter). This, I would imagine, is akin to a java
public static final variable. I suppose we should also adopt the java naming
convention of using UPPERCASE_NAMES for the name of the invariant. Of
course, for a large number of related constants (such as error codes)
binding to a service program, or including a "constants" module in your
program for this purpose seems like overkill. /COPY would probably do the
job easier, and with less overheads (during development, subsequent program
maintenance, and runtime). 
 
<Kurt said>
You're right. Since the use of Const in a procedure parameter means that the
recipient cannot modify the field, the keyword Const on a variable should
also mean the same thing; so it could be modified within the module, but
outside the module there is only 'read only' access to it.
</Kurt said>
 
It's pretty easy to have a variable that is "considered" to have read-only
access outside it's parent module, but read-write access within it's parent
module. You simply use standard accessor methods - make the variable private
and use an exported getter subproc and a non-exported setter subproc.
 
Some of the advantage of using accessor methods over read-only exported
variables would be:
 
1) Encapsulation of the data.
Once you have encapsulated the data you could even move your constants out
of the module and still allow access via the getter subproc(s) - how you
implement the retrieval is of the data internally is totally independant of
the way you present your data externally. This affords you considerable
flexibility when (re)designing your application.
   
2) The ability to return data as various data types.
You could store data internally as an int, for example, but you can create
different getter subprocs that return the data as a short, int, zoned
decimal, packed decimal, string representation - anything you want. I have a
service program that exports subprocs used to retrieve the value of the C
runtime global error code (or any internally overriden value - encapsulation
again!). This value can be retrieved as either an int or a 4,0 zoned decimal
field. The int is used in various other subprocs, and the 4,0 zoned
representation is used to retrieve any overridden error descriptions from a
message file.
 
For example:
  if returnCode = -1;
     errorDesc = getMessageDesc(getMessageID(getErrorCode4S()));
  endif;
 
Here, getErrorCode4S() returns the global (or overridden) error code as a
4,0 zoned decimal, getMessageID returns a 7A message ID, and getMessageDesc
returns a 132A description. This is displayed on the screen in a message
subfile. (I use this in my little RPG web client for testing HTTP requests
from our iSeries)  
  
3) The ability to control access to the data.
This is the big one for me. :-) At the moment you can "programatically" code
your own access control code. You can pretty-much do anything you want here
to control data access. It would be nice to have more control boundaries for
exporting data. But I can't complain - RPG is sooooooo much more than it
used to be! <grin/>  
 
Cheers
 
Larry Ducie