I've followed this "module" thread with great interest
having struggled with many of these same issues. My feeling
is that all this machination over interfaces results from
not passing the procedure as an argument. If it were passed
as an argument, then all interface concerns are satisfied, no?
There are certainly valid reasons for choosing not to use
procedure arguments (e.g., the procedure isn't needed till
several layers down), and I often do choose to hardwire a
call to an external procedure instead. Looking forward to
F2K, my view is that pointers to procedures will solve a lot
of these problems. (There will be procedure pointers in F2K
won't there?) If I have a library module (A) that needs to
call a user routine, (A) can provide a subroutine that will
will "register" the routine by storing a pointer to it in
private data (perhaps a component of a derived type which
encapsulates the entire state of the library). This way I'm
not forced to choose between hardwiring an external call and
awkward/unnatural procedure arguments.
-Neil
--
Neil Carlson Voice: 505-665-1220
Motorola Computational Materials Group FAX: 505-665-5757
Los Alamos National Laboratory [log in to unmask]
Mailstop B221, Los Alamos, NM 87545 [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|