You might be right. Probably I am fixating on something that I do not
understand well and just have a not positive feeling about it. But two
things:
1 - Other packages (will) have implementations that satisfies first.cloner
so there might be:
type cloner interface {
Clone() (*third.State, error)
}
Should I put the State struct in it's own package? (Seems to be a logical
solution.)
2 - Being forced to import the dependency explicitly, while I expect just
to be able to accept it as an interface, in a NewX constructor, is
nullifying the whole fantastic game of interfaces. State is a POGO (as in
POJO or POCO - plain old Go object, just an analogy).
On Saturday, April 21, 2018 at 4:36:40 PM UTC+4:30, Axel Wagner wrote:
>
> On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian <kaveh.sh...@gmail.com
> <javascript:>> wrote:
>
>> Is there a way to actually achieve this?
>>
>
> Either change `second.cloner` to return an interface, or (IMO better) just
> import `second`. I don't understand why you'd want to avoid that.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
