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
- 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