× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.