RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

[Rich Duzenbury <rduz-midrange@xxxxxxxxxxxxxxxxxxx>]

>   This, by
> the way, is another reason that I advocate moving ALL file I/O for a
> file into a single module; it avoids some of these issues.  It sometimes
> causes a little extra upfront work, but in the end it makes your life a
> lot cleaner.

I've been coding RPG since '84, so I'm somewhat of a dinosaur in this regard.

I haven't been convinced (yet!) that it's better to have the file I/O in 
one module.  With the existing code, I can look at the F specs and see what 
gets read and/or updated.  I can scan for CALL and see any programs that 
might also update a file.

With procedures, the code is much more intertwined, and it doesn't seem as 
easy to be sure what a particular program might be doing to the database.

Some opinions are that this makes for easier maintenance.  In the case of 
RPG, I've seen approaches of this type where the record layout is pulled 
into the main program via an external data structure.  The procedure then 
reads the record from the database, loads it into the data structure, and 
then returns the data structure to the main program.  This doesn't appear 
better than just having the file defined in the main program, as any change 
to the underlying table will surely require a recompile of both the main 
program and the procedure in the event that fields are added to the table 
or changed.

I'm trying to think of other systems where using a function to do the I/O 
and passing back a data structure is done.  I can't think of any.  For 
example, when I write Perl code to access a MySQL database, I generally do 
it as simply as possible:

my $dbh = connect();

# Get last name, first name from the table
my $sth = $dbh->prepare( "SELECT ulnam, ufnam FROM person") ;

$sth->execute;

while ($row = $sth->fetchrow_hashref) {
    # do stuff with each row
}

I don't try to write a function that returns a data structure for each 
record, although I suppose I could.  The reason I write it this way is 
because it's clear and concise.  I could build this as a routine that 
forces the user to implement a call-back to get back each row.  I could 
somehow use a static variable or parameter to indicate whether the query 
should be run, and then return each row on successive calls to the 
function.  I don't see how that's easier or better.

I don't try to write an object that returns a data structure for each 
record, although I suppose I could. I could have an object with a method 
for setting the desired database key.  I could have another method for 
executing the query.  And another for returning each row.  But why?  It's 
building a new interface that's not necessary.  There is already a direct 
interface to the database.  Why recreate it?  Anyone familiar with the 
database can already retrieve any data in it.  If you force someone to 
learn your object-ified way of accessing the data, it seems to me you are 
getting in the way of getting the job done.

If I have this code in 100 different programs, and it has to change, I 
think that's probably OK.  The reason is - if you have to change the query 
to return a new field, say for example, the person's middle initial, I also 
have to change all of the callers to actually *do something* with that new 
element.

I'm not trying to rain on your parade, I am just interested in 
understanding what the rationale is.

Regards,
Rich