Re: [Boost-build] Python port: globals

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

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

Best regards,

Johan Nilsson