Re: Granularity of Modules. -- RPG400-L

*       Several sources I have read imply that a module should consist
of a single sub-procedure.


Problems:

a) This makes it impossible for two routines to share an open file.Consequently, every routine has to have it's own open files and that'sjust not efficient. It also causes havok with record locking (if you'renot very careful.)

b) It leads to a monolithic programming mindset. It's true that you CANwrite modular code with only one procedure per module, but what tends tohappen is that people start to think of modules the same way they think ofprograms (which also have only one entry point) and programmers tend tofall back on the way they've always done things, automatically. Thisleads to the monolithic code and defeats the purpose of modularization.

c) As alluded to in the previous point, you're really throwing away theadvantages of ILE and modular design in general. You have nothing withthis approach that you couldn't already do in OPM programs. Well, otherthan the speed boost of calling a bound procedure instead of a dynamiccall... which is rarely significant.

I think one-procedure-per-module is a very poor design choice. And itdoes lead to a maintenance nightmare as well, as you'll soon be dealingwith 15000 source members instead of 200. Yuck.

*       I can live with the idea of more than one sub-procedure in a
module as long as they are only used locally, but I'm having trouble
with the idea of modules with more than one sub-procedure. The compiler
allows this to occur and to my mind it must be very difficult tracking
the relationship between programs, modules, and sub-procedures.

I disagree wholeheartedly. In my experience putting only one procedure ina module is an absolute maintnenance nightmare.

And please do remember that there are a lot of people with experience onthis subject. RPG has had this capability for more than a decade now, andevery other language has had the capability for longer. Every programwritten for every computing platform uses modular code. Try to find asignificant software project in C where they put only one function perobject. Try to find one in C++. Try to find some non-trivial Javasoftware where all of the classes have only one method. I bet you can't,in any of these cases. I could go on to name more languages and platforms-- nowhere in any modern language to people limit themselves to oneprocedure per module. The ONLY time people do that is when they're usinga non-modular language like RPG III, where there's no choice.

*       My other beef with the module/sub-procedure relationship is the
size of the name - if the sub-procedure name can be 15 and the source
member name is 10, then we immediately have an issue. I am then faced
with having to have a naming standard which encodes the sub-procedure
name, or have to restrict my sub-procedure names to 10 characters.

Not sure where you got the number 15 from. (Subprocedure names can be, forall practical purposes, any length you want.)

I don't understand why a 25 character naming standard is a problem --other than it's cumbersome to type -- and I don't understand why you needto restrict your subprocedure names to 10 characters. Is there somewherethat it's important to have 20 character names or less?


I'm lost.

Do other ILE developers restrict themselves to a single sub-procedure in
their modules?

I don't know of any successful implementation of ILE or any other modularenvironment where they've done this. Only in OPM or comparablenon-modular languages do people do this.