utils/registry: TypedNameVersion registry

utils/registry: TypedNameVersion registry

As part of getting API versioning in place, I was putting together some
Registry's in a couple of places. I realized I wanted 2 things that were
essentially identical code, just tracking slightly different object
types. So I put together an abstraction that still enforces the Type,
but is otherwise treats the input and output as a generic interface{}.

I'm not stuck on the naming, though I went with
registry.TypedNameVersion as the handle for this thing. I could just as
easily calling simply registry.Registry and the fact that it enforces
Types and uses Name+Version as the key can just be in the docs.

I'm not 100% sure that we'll strictly need this, as the code is evolving
to where I may only have 1 registry. However, it still seemed like a
useful bit of functionality, and it was easily split out from the other
work as a self-contained and well tested bit of work.

If we prefer, I can wait to land this until it is clearly necessary
(rather than just having a single Registry that has a fixed object
type). But if we ever have >=2 registries with different types, I think
we'll want something like this.

https://code.launchpad.net/~jameinel/juju-core/typed-registry/+merge/219161

(do not edit description out of merge proposal)

[jameinel, 2014-05-12 09:35:43]

Please take a look.

[fwereade, 2014-05-13 07:25:00]

I'm also not sure that we'll end up using exactly this, but LGTM all the same;
just please remember to drop it if it turns out that we don't.

[jameinel, 2014-05-15 08:01:34]

Please take a look.

[rog, 2014-05-22 12:50:53]

Saw this in passing - it looks reasonable, although with all the talk of
"versions" and "facades" it seems as if it it might fit better as a subpackage
of or within the rpc package.

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go
File utils/registry/registry.go (right):

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:16: // defined when the registry was created. It will
be cast during Register so
I'm not sure I see the use case for the conversion logic. Wouldn't it be simpler
just to stipulate that the same type must always be registered for the same
name?

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:21: versions     map[string]Versions
Another possibility might be to hold a single map with a struct{name, version}
key. Then Get is only a single map lookup and List could be simpler too.

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:38: // Versions maps concrete versions of the
objects.
a) this doc comment doesn't say what it maps from.
b) it looks as if the Versions type doesn't actually need to be exported.

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:41: // Register records the factory that can be used
to produce an instance of the
This comment doesn't seem to make sense in terms of the functionality of this
package. There's nothing factory-like going on here, although it's certainly
possible to store functions in the registry; similarly "facade" doesn't really
have any meaning here.

// Register records the object associated with the given name and version.
// The object must be of the same type passed to NewTypedNameVersion.

?

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:52: if r.versions == nil {
How can this happen, assuming NewTypedNameVersion has been used?

https://codereview.appspot.com/99180044/diff/20001/utils/registry/registry.go...
utils/registry/registry.go:97: // facade is not found, it returns error.NotFound
I'd prefer to see a bool return here to make it clear that
there's only one kind of error (and it's closer to the map
interface too, which is essentially what this type is)