Re: Exported Variables (was Long Constant Names)

This is one of the reasons I would like to have an option to define
prototype variables and data structures. The prototype variable would
only be used by the compiler as a reference for variables defined LIKE
the prototype. The prototype wouldn't be associated with any memory and
would not be allowed to be used outside the D specs. 

Another option might be to allow modules to export variables as
prototypes. In the importing program the prototype variable would only
be allowed to be used as a reference in Like or LikeDS.

A related request would be for built in prototypes for the various
simple types, such as integer, long integer, float, pointer, indicator,
etc. I find it more readable if I define an integer variable
"Like(Integer)" rather than 5I0. But I don't like needing to include a
list of prototype variable definitions for each of the simple types. It
might even be nice to allow definitions like "Like(Packed:9:2)", 
"Like(Char:100)", or maybe "Like(Char:100:varying)". Maybe when we get
free format D-specs.

Joe Lee

>>> rob@xxxxxxxxx 01/07/2005 08:00:26 >>>
I don't like LIKE in a prototype probably because of your reason 2, but

worded differently.  I put my prototypes in a /copy.  I don't want to
have 
to count on the variable I am doing a LIKE on existing in the program I

add the prototype to.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com 





"Paul Morgan" <pmorgan@xxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx 
01/07/2005 10:46 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx 
cc

Subject
Re: Exported Variables (was Long Constant Names)






Barbara,

Pass-by-copy would be best.  Good to see that it's on a future
enhancment
list.

BTW, I object to using LIKE definition in a prototype because:

1) It violates the idea of a procedure as being immutable.  If the 
interface
changes it requires retesting.  You want to avoid changing the
interface 
at
all costs.  Better to write a new replacement interface if the
variable
changes. (this also applies to LIKE definitions in a procedure
interface)

2) It sort of defeats the purpose of encapsulation.  Another variable
must
be brought out of the internals of the procedure just to use the 
prototype.
Why make me code a data structure or variable just to define a
parameter 
in
a prototype?  More extra variables I don't really need in my calling
program.  Makes the procedure unwieldily.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333
"Barbara Morris" wrote

> I think CONST is working correctly to stop the compile.  (We do have
a
> "pass by copy" parameter-passing-mode on our possible future
> enhancements list.)
>
> Defining the parameter-passing temporary LIKE the constant would
only
> work if it was the same type as the prototyped parameter. I guess it
> would be a good practice to define every by-reference prototyped
> parameter LIKE or LIKEDS something, so that temporaries could be
easily
> defined LIKE or LIKEDS the same thing.
>
>  D myproc_types         ds              qualified
>  D                                      based(typedef_dummy)
>  D   myparm                        10a
>
>  D myproc               pr
>  D   myparm                             like(myproc_types.myparm)
>
>  ...
>
>  D myparmTemp           s               like(myproc_types.myparm)