Exporation and Encapsulation

>By laying bare your internal variables you restrict your ability to
re-design your module code. 
Well said.

In regard to the Export/Import feature, maybe if IBM allowed us to
specify the Const keyword along with the Export keyword, then subsequent
modules would have access to the value w/o being able to change it (much
like procedure calls).

I'm guessing there is less performance usage in Export/Import vs
encapsulation, but encapsulation does provide the most control.  Of
course, there's always parameter passing as well, but I'm guessing the
question of field exportation and encapsulation comes into play when
there is a lot of random field usage between programs and the question
of which parameters are required isn't black and white (and you don't
feel like passing them all all the time).

While I have used encapsulation, I think if the Export/Import feature
were further expanded upon, it'd be a really nice tool.

Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry
Sent: Friday, December 17, 2004 2:06 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Procedure pointers - can I do this??

Hi Kurt,
 
<snip>
I have never implemented what I'm about to mention, and I don't know if
this is what you're looking for, but...

If you have a module that calls other modules, those other modules can
access fields (or Data Structures) from the first module if you define
those with the Export and Import keywords.
Module 1:
D Ind1            S               N   Export

Module 2:
D Ind1            S               N   Import
</snip>

That's an interesting idea. I'd find it scary if it worked. Personally,
I'd rather use getter methods to retrieve variable data across module
boundaries. My reasoning is that, as RPG only really has two access
modifiers - PUBLIC (exported) and PRIVATE (not exported), you can't have
"package" or "protected" access to your own data. Thus, if you export a
variable from one of your modules you are allowing it to be modified by
ANY client program that binds to your service program. You may want some
of your own programs access to the data, but not ANY program. The only
safe way to allow "restricted" access is to encapsulate the data through
sub-procs. The sub-proc can then perform some form of validation prior
to returning the variable data. The other beauty of encapsulation is
that you can modify HOW you generate the data internally, and return
different values in different scenarios. By laying bare your internal
variables you restrict your ability to re-design your module code.
 
Cheers
 
Larry Ducie   
--
This is the RPG programming on the AS400 / 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.