Re: Please, no more types called "State"
I see the point. But it could be considered analogous to having lots of methods called New() etc. So long as the types are relevant for the package in which they're declared then isn't that ok? If we have lots of packages where state needs to be persisted, how is that different to having lots of packages where a struct needs to be created, hence there will be several different New() methods. Many of the current usages are client facades in the various API packages, which is indeed unfortunate and I wish were different. But let's not universally reject State types without considering the intended semantics. On 12/03/15 15:01, David Cheney 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
Re: Please, no more types called "State"
On 12/03/15 18:13, Ian Booth wrote: > I see the point. But it could be considered analogous to having lots of > methods > called New() etc. So long as the types are relevant for the package in which > they're declared then isn't that ok? If we have lots of packages where state > needs to be persisted, how is that different to having lots of packages where > a > struct needs to be created, hence there will be several different New() > methods. > > Many of the current usages are client facades in the various API packages, > which > is indeed unfortunate and I wish were different. But let's not universally > reject State types without considering the intended semantics. *cough* *bullshit* *cough* State is a terrible name for a structure. I've also heard you say as much before too. I think people have just gotten lazy, and rather than thinking of a more appropriate name, just use State because others have. I know I'm guilty of doing this. I'm with Dave on this one. Think about this... describe the job to someone (or a teddy bear). Sure it is the state of the instance, but the state of what? Tim > > > > On 12/03/15 15:01, David Cheney 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
Re: Please, no more types called "State"
On Thu, Mar 12, 2015 at 2:53 PM, Tim Penhey wrote: > On 12/03/15 18:13, Ian Booth wrote: > > I see the point. But it could be considered analogous to having lots of > methods > > called New() etc. So long as the types are relevant for the package in > which > > they're declared then isn't that ok? If we have lots of packages where > state > > needs to be persisted, how is that different to having lots of packages > where a > > struct needs to be created, hence there will be several different New() > methods. > > > > Many of the current usages are client facades in the various API > packages, which > > is indeed unfortunate and I wish were different. But let's not > universally > > reject State types without considering the intended semantics. > > *cough* *bullshit* *cough* > > State is a terrible name for a structure. > So, I'm sure you know this, but for reference: I am the perpetrator of the latest State. Context is important to a name, and in this case I think it's obvious enough from the context what the type name means. I even made the type unexported, so we wouldn't have to have this discussion. (The grep shows it up because it's exported to tests in same package.) I've also heard you say as much before too. > > I think people have just gotten lazy, and rather than thinking of a more > appropriate name, just use State because others have. I know I'm guilty > of doing this. > I object to the implication that I did this out of laziness. There's two reasons why I went ahead with the name "state": 1. I *did* think about this, but couldn't think of a better name. When I asked for suggestions, I was met with silence. It's fine to say something's bad, but please explain why and suggest alternatives. 2. Other have used the name :) To expand on the second point: this is not just "he did it, I'll just copy him and stop thinking now", it's "we have a precedent here, let's converge on a single vocabulary". The uniter/storage package, where this state type exists, is *very* similar to the uniter/relation code. If we're going to invent new names, we should at least be consistent about it. These bits of code are state machines; state machines require state. I'm with Dave on this one. > This just seems like a knee-jerk reaction to an often-used name. I've yet to hear a cohesive argument from anyone about why the name isn't meaningful, just "it sucks, don't do it". Think about this... describe the job to someone (or a teddy bear). Sure > it is the state of the instance, but the state of what? I don't understand this. If it's the state of something, how is "state" not an apt description? Are you suggesting it should State instead of State? If not, can you give an example of where State is used and a better name? I think what Ian was saying in the first paragraph is that the is, in some cases, implied by the context. /rant Cheers, Anrew > Tim > > > > > > > > > On 12/03/15 15:01, David Cheney 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
Re: Please, no more types called "State"
On 12/03/15 16:53, Tim Penhey wrote: > On 12/03/15 18:13, Ian Booth wrote: >> I see the point. But it could be considered analogous to having lots of >> methods >> called New() etc. So long as the types are relevant for the package in which >> they're declared then isn't that ok? If we have lots of packages where state >> needs to be persisted, how is that different to having lots of packages >> where a >> struct needs to be created, hence there will be several different New() >> methods. >> >> Many of the current usages are client facades in the various API packages, >> which >> is indeed unfortunate and I wish were different. But let's not universally >> reject State types without considering the intended semantics. > > *cough* *bullshit* *cough* > > State is a terrible name for a structure. > > I've also heard you say as much before too. I've complained about the examples I gave in my response (State types in the API facades) plus the big ball of mud which is the state package itself. But bespoke usages of State types in the correct context need to be considered individually and not universally rejected because we misuse State elsewhere. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
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 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
Re: Please, no more types called "State"
On 12 March 2015 at 07:22, Andrew Wilkins wrote: > On Thu, Mar 12, 2015 at 2:53 PM, Tim Penhey > wrote: >> >> On 12/03/15 18:13, Ian Booth wrote: >> > I see the point. But it could be considered analogous to having lots of >> > methods >> > called New() etc. So long as the types are relevant for the package in >> > which >> > they're declared then isn't that ok? If we have lots of packages where >> > state >> > needs to be persisted, how is that different to having lots of packages >> > where a >> > struct needs to be created, hence there will be several different New() >> > methods. >> > >> > Many of the current usages are client facades in the various API >> > packages, which >> > is indeed unfortunate and I wish were different. But let's not >> > universally >> > reject State types without considering the intended semantics. >> >> *cough* *bullshit* *cough* >> >> State is a terrible name for a structure. > > > So, I'm sure you know this, but for reference: I am the perpetrator of the > latest State. > > Context is important to a name, and in this case I think it's obvious enough > from the > context what the type name means. I even made the type unexported, so we > wouldn't > have to have this discussion. (The grep shows it up because it's exported to > tests in > same package.) > >> I've also heard you say as much before too. >> >> I think people have just gotten lazy, and rather than thinking of a more >> appropriate name, just use State because others have. I know I'm guilty >> of doing this. > > > I object to the implication that I did this out of laziness. There's two > reasons why > I went ahead with the name "state": > 1. I *did* think about this, but couldn't think of a better name. When I > asked for >suggestions, I was met with silence. It's fine to say something's bad, > but please >explain why and suggest alternatives. > 2. Other have used the name :) > > To expand on the second point: this is not just "he did it, I'll just copy > him and > stop thinking now", it's "we have a precedent here, let's converge on a > single > vocabulary". The uniter/storage package, where this state type exists, is > *very* > similar to the uniter/relation code. If we're going to invent new names, we > should > at least be consistent about it. These bits of code are state machines; > state machines > require state. For those types, I wonder if a "LocalState" name convention might work OK - so we'd know that these types are about maintaining the local state of the uniter rather than communicating with the global juju state. That said, the doc comments are clear and I doubt you're going to be confused for long by that code. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
On 12/03/15 05:01, David Cheney wrote: lucky(~/src/github.com/juju/juju) % pt -i type\ State\ | wc -l 23 Thank you. When I was new to Juju the fact that we had a central "State", core to the Juju model, but we had umpteen types called State - so where you saw a State you had no idea what it actually was and when someone mentioned State you couldn't be sure what they meant - was a significant part of the learning curve. Perhaps a better solution would have been a better name for the core State. Michael Dave -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
When I was new to juju myself, we only had one State, I believe. That one golden state was supposed to represent the state of the whole deployment, so it was indeed The State of the system. Having tons of these indeed sounds awkward. On Thu, Mar 12, 2015 at 8:08 AM, Michael Foord wrote: > > > On 12/03/15 05:01, David Cheney wrote: >> >> lucky(~/src/github.com/juju/juju) % pt -i type\ State\ | wc -l >> >> 23 >> >> Thank you. > > > When I was new to Juju the fact that we had a central "State", core to the > Juju model, but we had umpteen types called State - so where you saw a State > you had no idea what it actually was and when someone mentioned State you > couldn't be sure what they meant - was a significant part of the learning > curve. > > Perhaps a better solution would have been a better name for the core State. > > Michael > > >> >> Dave >> > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
> Perhaps a better solution would have been a better name for the core State. > > Michael + 1 Also matches my sprint topic about an improved management of our persistency (separation of model types and interfaces for their persistency; grouped by domains; instantiated by factories to allow proper mocks here). mue -- ** Frank Mueller ** Software Engineer - Juju Development ** Canonical -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
On Thu, Mar 12, 2015 at 5:08 AM, Michael Foord wrote: > When I was new to Juju the fact that we had a central "State", core to the > Juju model, but we had umpteen types called State - so where you saw a State > you had no idea what it actually was and when someone mentioned State you > couldn't be sure what they meant - was a significant part of the learning > curve. I had the same experience. > > Perhaps a better solution would have been a better name for the core State. +1 -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
The core state (The State) is the one case where it doesn't matter, IMO. Everybody knows what it is. It's the other dozen that create the issue, and they will remain as ambiguous if you just rename the one State. On Thu, Mar 12, 2015 at 11:23 AM, Eric Snow wrote: > On Thu, Mar 12, 2015 at 5:08 AM, Michael Foord > wrote: >> When I was new to Juju the fact that we had a central "State", core to the >> Juju model, but we had umpteen types called State - so where you saw a State >> you had no idea what it actually was and when someone mentioned State you >> couldn't be sure what they meant - was a significant part of the learning >> curve. > > I had the same experience. > >> >> Perhaps a better solution would have been a better name for the core State. > > +1 > > -eric > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Please, no more types called "State"
On 12 March 2015 at 14:23, Gustavo Niemeyer wrote: > The core state (The State) is the one case where it doesn't matter, > IMO. Everybody knows what it is. It's the other dozen that create the > issue, and they will remain as ambiguous if you just rename the one > State. The majority of those (17/20) are client-side proxies for The State. Perhaps they could all be renamed "StateProxy" - that wouldn't be bad. But when you're writing code that uses the type, the semantics won't be too different whether you're invoking an operation over the network or not (with the exception of additional possible network failure modes of course, which largely still exist even in the non-proxied State type because we're talking over the network to mongodb), so I still think that State makes sense for those types. > > On Thu, Mar 12, 2015 at 11:23 AM, Eric Snow wrote: >> On Thu, Mar 12, 2015 at 5:08 AM, Michael Foord >> wrote: >>> When I was new to Juju the fact that we had a central "State", core to the >>> Juju model, but we had umpteen types called State - so where you saw a State >>> you had no idea what it actually was and when someone mentioned State you >>> couldn't be sure what they meant - was a significant part of the learning >>> curve. >> >> I had the same experience. >> >>> >>> Perhaps a better solution would have been a better name for the core State. >> >> +1 >> >> -eric >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > -- > > gustavo @ http://niemeyer.net > > -- > 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
Re: Please, no more types called "State"
I just wanted to pile on: alone, I don't think State is a terrible name for what these types represent in their respective packages. The issue is that the canonical usage of state is universally meant to refer to "The State". It's this context that makes it confusing. Roger's suggestion of "StateProxy" doesn't sound bad. I also agree with Andrew's comment about converging on vocabulary. Consistency > perfect but different for the singular reason that if things are consistent, you can address the issue wholistically later. - Katherine On Thu, Mar 12, 2015 at 9:23 AM, Gustavo Niemeyer wrote: > The core state (The State) is the one case where it doesn't matter, > IMO. Everybody knows what it is. It's the other dozen that create the > issue, and they will remain as ambiguous if you just rename the one > State. > > On Thu, Mar 12, 2015 at 11:23 AM, Eric Snow > wrote: > > On Thu, Mar 12, 2015 at 5:08 AM, Michael Foord > > wrote: > >> When I was new to Juju the fact that we had a central "State", core to > the > >> Juju model, but we had umpteen types called State - so where you saw a > State > >> you had no idea what it actually was and when someone mentioned State > you > >> couldn't be sure what they meant - was a significant part of the > learning > >> curve. > > > > I had the same experience. > > > >> > >> Perhaps a better solution would have been a better name for the core > State. > > > > +1 > > > > -eric > > > > -- > > Juju-dev mailing list > > Juju-dev@lists.ubuntu.com > > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > -- > > gustavo @ http://niemeyer.net > > -- > 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
