Please, no more types called "State"

[Ian Booth]

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.