I agree with Jake: a more complete example would be helpful. In my
experience, this sort of issue is often a symptom of awkward package
boundaries. If you can find a more natural package boundary, you may be
able to sidestep the problem.
(There are certainly some cases where the lack of covariance makes
interfaces difficult to construct, but those cases tend to be rare.)
On Monday, April 23, 2018 at 12:08:38 PM UTC-4, Jake Montgomery wrote:
>
> My gut feeling is that there is an elegant way to achieve what you want.
> Unfortunately, I am having trouble following the code you are describing,
> and more importantly, what you are actually trying to accomplish. Perhaps
> it is my failing.
>
> If you would post a more complete example, showing the relevant code in
> all the related packages, I suspect you would get constructive suggestions.
>
> - Jake
>
>
> On Saturday, April 21, 2018 at 7:51:55 AM UTC-4, Kaveh Shahbazian wrote:
>>
>> 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.
