On Monday, 29 May 2017 23:44:32 UTC+3, Darko Luketic wrote:
>
> Humm.. I wrote a reply but it seems it only reached Justin and not this
> group.
> Also I have not received other replies via email.
>
> Ok...
>
> Ayan, no that's alright it was storage.UserModelInterface
> and I know what you're al
On 05/29/2017 04:44 PM, Darko Luketic wrote:
>
> Ayan, no that's alright it was storage.UserModelInterface and I know
> what you're all saying but I saw no other way to make them type
> agnostic and I'm a fan of explicitly calling things what they are
> especially when I'm experimenting. And
Humm.. I wrote a reply but it seems it only reached Justin and not this
group.
Also I have not received other replies via email.
Ok...
Ayan, no that's alright it was storage.UserModelInterface
and I know what you're all saying but I saw no other way to make them type
agnostic and I'm a fan of e
Before we put the focus on criticism of the OP's code organisation, it's
well worth investigating the likely code bug first.
>but when I use var m storage.ModelInterface and then call a member
function of the interface (SetName) Go panics because nil pointer
dereference
Based on this problem descr
Don't put organize by structure, this is what seems to be causing the most
of the damage,
I would suggest implementing as:
assets/*
cmd/root.go
cmd/server.go
storage/mongo/user.go
storage/id.go
user/user.go
user/service.go
forum/server.go
main.go
User package would look like:
package user
im
