This will become a description of the evolution of an approach for
designing complex, event driven Perl programs. I'd be very much
interested in opinions on it, should someone be willing to share one.

1. Subsystems
-------------

This was the starting point and it basically came from C: Implement each facility of such a program (usually, signal dispatcher, I/O event
handling, timer processing and some application-specific ones) as a
subsystem, that is, a module keeping whatever state is required in
file-scope my variables and exporting a set of subroutines so that other modules can make use of the provided facility.

This would usually result in an odd mix of procedural and
object-oriented code.


2. Classes & Access Modules
---------------------------

An intermediate step: Implement each subsystem as a class even if there
can be only one of them. Use a module exporting (@EXPORT) a single
anchor variable with a well-known name. This anchor variable will be initialized to an instance of the class providing the service during
program initialization. Other modules which want to make use of a
faciliy import the anchor variable and use whatever happens to be
provided by doing method calls via that.

Benefit of this approach is that it gets rid of most of the exporting
and importing (and the associated possibilty of nameclashes). It also
leads to a looser coupling between independent modules which no longer
have any information about each other's implementation.

The main drawback is that two modules for each facility are needed and
that the anchor variable module is essentially boilerplate text.


3. Classes & Variables in main
------------------------------

Create classes as described above but get rid of the anchor variable
modules. Instead, use package variables in namespace main for
that. These can be accessed from anywhere in the programm by prefixing
the name of the variable with v::, eg

$::timer->add(<parameters for new timer>)

There's no need to export of import anything anymore. Further, all
general modules are independent of each other. Only the main program
module needs to know which facilities are provided by which other
module.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)