RE: Procedure pointers - can I do this??

["Larry Ducie" <larry_ducie@xxxxxxxxxxx>]

Hi Scott,

<snip>
Instead of having trust between different service programs, maybe you could 
set them up as modules? I.e. have a large service program that's made up of 
a main module, and possibly several utility modules.
</snip>

This is where my implicit distrust of exporting "data items" stems from. 
Although I totally agree, I would want my modules to be, well "modular", and 
independant. I like the idea of modularity, but allowing inter-modular 
access (and possibly dependance) of data items would imply that I am on the 
road to generating super-modules. That is, module pairs/groups that depend 
upon each other's data items for normal use. In the past I would simply 
group these together and create a utillty service program. In fact, I would 
generally code my service programs that way - exporting the procedures that 
will be useful to client programs.

It just seems to me that we're replacing subroutines with sub-procs for the 
very same reasons why we shouldn't be exporting data items accross module 
boundaries. Funny really, allowing sub-procs to have their own copies of 
data during an intra-module procedure call, but exporting the same data to 
another module via data item exports. :-)

<snip>
You can perform "late binding". There are various APIs that you can call at 
runtime that will locate a service program, activate it, and retrieve a 
procedure pointer to one of it's routines. You can then call that procptr...
</snip>

You know, I love this language. I jusk know I'm going to be spending "a lot" 
of the Christmas period thinking about that little gem. :-)

Cheers

Larry Ducie