Improvement: Add ObjectLifeCycle pattern methods to all structs

[OmidHekayati]

• When All structs have ObjectLifeCycle methods(Init(), Reinit(), Deinit()), All developers can easily track the object life cycle.
• If an object needs huge allocation and prefers to reuse after the first usage (with proper benchmarks), we can easily reuse them
• If a struct needs to be embedded in another struct, we always track easily how and why! e.g. I can't understand why state.LoadOrNewState() return Facade interface type instead of a pointer to its type as state and even why state type is internal to its package! It is tough to track all usage of returned Facade and how others use or keep a reference to it and also hard to make suggestions to improve performance.

[OmidHekayati]

In other words, API must be flexible. Accepting Interfaces and Returning Structs.

Robustness principle say:
be conservative in what you do, and be liberal in what you accept from others.

[b00f]

In large modules like state, we have defined an interface (like Facade in state).
By following this approach, we can easily mock a large object (like state) for testing purposes.

[OmidHekayati]

Yes, You get it rightly. When using this signature format like func LoadOrNewState(...) (*state, error) can easily assign to any Facade variable type, So it is not breaking any codes. It can be the start to improve performance to emit unnecessary interface usage.

[b00f]

@kehiy go ahead man! Let's make @OmidHekayati happy!

[kehiy]

I like to make Omid happy too, but I think resolving this conversation is more than I can (maybe) 😄
how much time do we have?

[OmidHekayati]

@kehiy Don't bother yourself. I just suggest, So It is a COULD, not a MUST. You have infinite time to solve performance issues!

[kehiy]

yeah, that's true, for now, I have another task after it I go thorough context issues then this one...