Non-parochial namespaces

[dottedmag]

Namespaces in Game are implemented as structs with methods.

This is not composable: e.g. one cannot expose a task in a namespace by assigning a function/Runnable a name, as one can do with regular tasks.

Investigate alternate ways to describe namespaces that do not involve creating a whole package.

[feldgendler]

I actually hate Mage's exports-as-targets approach. It's hard to get an overview of the targets, and their names get transformed, sometimes with ugly results.

I would rather have the top-level build.go exhibit a single export by a well-known name:

var Targets = game.Targets{
    "clean": build.Clean,
    "kraken": kraken.Targets,
    "something": func(ctx task.Context) { ... },
    ...
}

No namespaces, no guesswork based on imports. If you want nested “namespaces”, you include a nested game.Targets map like kraken in the example above.

(Yes, the underlying type of mage.Targets will have to be map[string]interface{}, but it will be immediately checked at runtime, so no big deal. And there are ways around this if you really hate it.)

If you do this, the next step after it would be to turn the top-level build.go into a normal program with a func main() that invokes Game as a library and passes the targets to it.

[feldgendler]

Oh, the design above loses the documentation strings. Well, that was just an example. The target list probably has to look a little more complicated than that, but the idea remains.

[dottedmag]

Yeah, something like that. Docstrings are an abomination too.