Fri Feb 29 13:50:02 CET 2008

utilities = language ?

Splitting brood in 3 components: brood, scat and zwizwa brings up the
problem of code bundling. there are 2 views of modules:

  - what they provide.

    this is the most important form of organization. there's a
    spectrum with 2 extremes: one object, and everything. the latter
    is a utility module, which is akin to a language. the former is a
    component module: an abstracted collection of code with a very
    limited interface.

  - how they are used.

    using component modules is straightforward: since they are often
    highly specialized, dependencies between components can be clean
    and understandable. using utility modules is not: granularity is
    much finer, and they behave more like "background noise": stuff
    you need to know about, but can assume to just "be there".

therefore, when using utilities in a project, like scat, it's maybe
best to take a single file and make sure it exports a non-colliding
set of tools. so the purpose of that single file is to be a decoupling
point, providing a language to the client, and importing small
utilities and components from all kind of different sources.

  so the approach i take is to have one collection of utilities
  (zwizwa-plt), and have a single file in each project that uses a
  base language with (a subset of) these utilities present.

an organic analogy:

     GRASS = all permeating language (base lang + utilities)
     TREES = specialized program components