Re: All the code in one place (was: OVERRIDES) -- RPG400-L

I guess what I was saying is that it's a GOOD idea, not a bad one, to
put overrides in the same member.

I'm not saying that all parts of an application should fit into one big
monolithic beast... not at all...

But the very basic rules of modular programming and (although it doesnt
really apply here) object-oriented programming specify that each routine
be responsible for it's own piece of the puzzle WITHOUT relying on
external functions to have already done something.

In the case of opening a file, part of the work is specifying which file
to open.  If it's the RPG program's responsibility to open the file
(which it pretty much has to be) then it's a GOOD idea to make sure
that it's also the routine that does the override.  If it should do so
based on some sort of external criteria, then these should be passed as
parameters, just like any other circumstance where external criteria is
involved.   i.e., it should be based on a well-designed interface to the
program.

When you specify the file on the F-spec in an RPG program, and then
specify it AGAIN in an external CL program, then you're splitting the
responsibility for opening the file between two different places.  That's
confusing and unnatural -- or at least it would be if we weren't so used
to it.

The fact that people ask questions about activation groups & overrides
either here or on midrange-l every other day makes it pretty clear that,
yes, in fact, this is confusing.


On Thu, 20 Dec 2001, Buck Calabro wrote:

> >> Thanks. What if the OVERRIDE is done
> >> in the RPG itself? I know,bad idea,
> >> but it's been like that forever.
> >
> >
> >Why is that a bad idea?  I think putting
> >it in the same RPG where the file opens
> >is the *best* way to go about it.
> >
> >IMHO, a well written program never relies
> >on other programs to make sure it does it's
> >job correctly.
> -snip-
> >This way, everything's right there
> >in front of the programmer.  He
> >doesn't need to search to find every CL
> >that might do different overrides
> >on a program.
>
> I have a slightly different view of this: there is no way that a modern
> application can be written with one source member.  I'm exaggerating for the
> sake of impact, but conceptually, I _want_ my programmers to think big.  I
> _want_ them to go out and look at the job stream before tinkering.
>
> Not that the participants in this thread have done so, but I have heard way
> too many RPG programmers refuse to use /COPY members, service programs and
> DDS (esp. printer files) because "I can't see the whole thing at once."
>
> Scott is right when he notes (indirectly) that code that operates together
> should be together, and he's surely right to note that an OVRxxx in a CL
> program far upstream has an effect on the downstream RPG program, but that's
> the nature of overrides.  It's also the nature of activation groups - they
> affect more than one program.  And that is the nature of modern
> applications, I think.
>   --buck