juju/names refactor part 2

[davecheney]

Introduce tag.Id() and tag.Kind() methods.

Prepare to alter the signature for ParseTag to return (Tag, error)

[rogpeppe]

In passing, why not just "type EnvironTag string" (and the others) ?

[davecheney]

On Wed, Jun 11, 2014 at 6:10 PM, rogpeppe notifications@github.com wrote:

In passing, why not just "type EnvironTag string" (and the others) ?

Two reasons, one major, one minor.

The major one was when I started I wasn't sure what kind of data each type
would have to model so making them all a struct to insure against adding
more data later. It has turned out that this wasn't needed.

The minor concern was to prevent people converting back to a string, by
making name (or id, or uuid, or key, or whatever) a private field, people
cannot convert a Tag implementation into a string out of frustration. I'm
open to arguments on both sides.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[howbazaar]

I do have to admit to preferring the struct approach as it actually names the string, like uuid for environment.

I've also been thinking in passing that a RemoteUserTag may well have two parts: username and identity provider (username@identity-provider)

[howbazaar]

since the result of the ParseTag function has changed I think
tag, id, err
would be better variable names.
Then kind.Kind() becomes tag.Kind() below.

[davecheney]

done

[howbazaar]

LGTM, we can refactor the tests later.

[davecheney]

Thanks. The very next branch refactors the test. This is just an interrum
step to make sure I the id value from ParseTag and Tag.Id() did not diverge.

On Thu, Jun 12, 2014 at 2:51 PM, Tim Penhey notifications@github.com
wrote:

LGTM, we can refactor the tests later.

—
Reply to this email directly or view it on GitHub
#3 (comment).