From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-09 03:27:23
Vladimir Prus wrote:
> While working on Python port, I have a question. In Jam code,
> most modules just dump all data as global objects. For Python,
> some already ported code departs from that habit -- for example,
> the project.jam port has class ProjectRegistry, that keeps the
> list of loaded projects. There's single top-level Manager
> object that keeps all the various classes together.
> This seems to be a good idea, and it makes the code more
> testable, and in future, it might be possible to have some IDE
> just load Python modules for Boost.Build, and then build several
> Boost.Build projects by just creating different "Manager" objects.
> OTOH, keeping everything as just globals is slightly easier to code.
> Anybody can comment, better with practical concerns, which approach
> is better?
For testability, a global point of access to everything is usually an
abhorrance. How do you you test code in isolation that depends on the
global? What happend if you at some point decide to go multi-threaded? Not
easy, and in the long run probably a real pain to maintain, leading to
untested code sneaking into the code base because it's so dang hard to test.
You could at least support the notion of a "settable singleton", where you
can change the actual implementation at runtime - e.g. during a specific
In statically typed languages the situation would still be terrible, as
you'd "have to" define an interface for the global access, and to be able to
plugin your "mocks" and "stubs" during unit testing they'd all have to
define the (probably) bloated global interface. In scripted languges the
situation is a bit better, as you can get away by only defining the actual
methods used in the unit tests by your "fakes".
For a minor project, one could probably still start out with the global
variant and transition to other strategies when the pain gets too high. For
Boost.Build, I believe that testability should be of priority.
Caveat: I've got zip experience from coding Python, but 5+ years of
Test-First Development using C++ (and occasional Ruby). That's where I come
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk