Re: [go-nuts] On Accepting Interfaces and Structs
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 > 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.
Re: [go-nuts] On Accepting Interfaces and Structs
On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian 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.
[go-nuts] On Accepting Interfaces and Structs
Regarding "Accept interfaces, return concrete types", how can it be applied
for structs that represent a payload/value?
For example in package first, logger is defined as:
type logger interface {
Debugf(template string, args ...interface{})
Errorf(template string, args ...interface{})
Infof(template string, args ...interface{})
}
And package first only accepts a logger that implements the logger
interface.
Now lets assume there is a need for passing a struct too, like some config
or state.
This causes importing the original package that, that config or state
struct resides in; while package first is happily accepting other things
from that package using interfaces.
For example in package second there is some tool that is represented using
this interface in package first:
type cloner interface {
Clone() (*second.State, error)
}
As it can be seen, now package first has to explicitly import package
second, because of the type *second.State.
Currently I break things by renaming the second package to something
meaningless when importing like:
type cloner interface {
Clone() (*p2nd.State, error)
}
But this is not really a work around and package second leaks into the
scope of package first anyway.
Is there a way to actually achieve this?
--
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.
