Every module gets an init

On load the LoadModule calls it. LoadModule looks like:

LoadModule ./home/so/fname arg1 arg2;

The LoadModule passes on the arguments, a standard procedure. The call to init looks like:

                 Init Execcommand xchars rectangle;

Where ExecCommand, the command search entry point is passed to every snippet.  For slush arg1 is the module name to xchars and arg2 name of the flush rectangle. Flush acquires the key value pair for xchars which is the entry point for namespace directed calls. Most snippets have an identifier key term, like rectangle, available in a front end symbol table. So the common form:
Entry Device; we will see a lot of, a binding standard.  IO manager gets initialized with a binding to PutStr for the command line rectngle. Flush binds to  Draw rectangle; to the flush box.  In both cases the rectangle destinations set up by initialization file in console loop.

Once the binding is made, the one snippet has a variable directly the method and device names specific to the called snippet, thus name space contract guaranteed, names unique in a name space domain. Using namespace to direct enterprise data flows, great architecture.. I have bind working with flush and today I go through an update of IO manger to do the same.  I ge a sample of two, I can test both and find where they are different and where hey re the same, pick the commonality and it becomes just that, a commons form. Having a common form for this reduces maintenance, lets me reduce line count.

Binding gives system control to the snippets and console loop is free to take the long search path without upsetting critical applications. argument pass through is natural on the Bus, w just assume the args is infinite, then one can see recursive nesting opportunities with commands. An untrue assumption, and console loop will eventually burp. But on a burp, console loop will eventually just allocate more args from linux. Or, in my application, it just resets the system back to the origin on args.