As the initial instigator of the API facade types named State, responsible
for 17 out of the 20 State types defined in non-test code, let
me explain my reasoning for those.
As I see it, all the facade types are windows on some particular
aspect of the global juju state. They all implement methods
that adjust or query the state through that window.
Thus in some sense they really are all signifying
different aspects of the same thing, and to
my mind if you've got two very similar things in different
packages, it makes sense to name them the same.
How else would they be named? uniter.UniterState ? We don't
like stuttering. uniter.Uniter ? That would seem to
signify the uniter agent itself, which is not the case.
It's more of a pity that we duplicate the uniter package
name (worker/uniter vs api/uniter) than the type name,
IMHO.
I would tend to agree that new types that do not signify
the global juju state should probably be avoided where
reasonable, but I also agree with Andrew that type names
are explicitly contextual in Go - it's one of the things
that allows us to be able to choose nice names
without fear of clashing or ambiguity.
cheers,
rog.
On 12 March 2015 at 05:01, David Cheney <david.che...@canonical.com> wrote:
> lucky(~/src/github.com/juju/juju) % pt -i type\ State\ | wc -l
>
> 23
>
> Thank you.
>
> Dave
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
