Use NewXxx functions instead of struct declarations

[rigelrozanski]

Throughout the entire sdk we should switch to using NewXxx functions
instead of allowing for struct definitions this will reduce errors as the compiler
will notify us everytime we update a struct but forget to update an object declaration
of that struct type.

[alessio]

I'd propose to adopt the NewXxx naming convention for constructors that return struct pointers, and MakeXxx for those that don't. E.g.:

func NewThing() *Thing {
        return &Thing{}
}

func MakeThing() Thing {
        return Thing{}
}

[cwgoes]

I'd propose to adopt the NewXxx naming convention for constructors that return struct pointers, and MakeXxx for those that don't.

Do we need to have constructors which return pointers? We should generally avoid using pointers.

[alexanderbez]

It's a case-by-case basis @cwgoes I think. But yes, majority of our types should not return pointers.

[alessio]

...thus let's use the MakeXxx naming convention, shall we?

[cwgoes]

...thus let's use the MakeXxx naming convention, shall we?

That's fine with me, but it will require changing a lot of current code. @rigelrozanski thoughts?

[rigelrozanski]

@alessio what to go into the thinking of using MakeXxx instead of NewXxx - I've never seen it before most libraries I see in golang use New.

did a bit of reading on some other's thoughts
https://grokbase.com/t/gg/golang-nuts/13btfsyhy7/go-nuts-what-should-i-name-a-constructor-if-it-does-not-return-a-pointer
https://www.reddit.com/r/golang/comments/9bkql2/stop_returning_errors_in_constructors_use/e53w7l1/

some of this is a little bit beyond me - but I'm not sure I see a good reason to deviate from just using NewXxx

[alessio]

Thanks @rigelrozanski, I thought about it again - we'd better to stick to a single naming convention only for simplicity's sake. Let's go with NewXxx() then 👍