FAQ
All,

I have read the "Go Concurrency Patterns" slides. I have a similar problem
to the "Google Search" described in the slides. See the example on Google
play: http://play.golang.org/p/wou66vpEG3

In the slides, Andrew made all three of the "query" methods return a
"Result" interface. I cannot refactor my code to extract a common
interface between my data retrieval methods because the structs have
different fields. The only common interface is {}interface. My example
program is also more complex because I have to deal with the query methods
returning error.

What do you all think about functions GetDataTwo and GetDataThree? Is one
preferred over the other? Is there another way to solve this problem that
I am missing?

Luke

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Egon at Aug 30, 2013 at 11:01 am
    If you need all the data to do something, just use the pointers:
    http://play.golang.org/p/EL6pq2pHQa

    Although it is less "safer", it simpler and easier to read than the channel
    communication thing. If you don't need all the values at the same time, the
    channel version is probably better.

    egon
    On Thursday, August 29, 2013 10:48:25 PM UTC+3, Luke Mauldin wrote:

    All,

    I have read the "Go Concurrency Patterns" slides. I have a similar
    problem to the "Google Search" described in the slides. See the example on
    Google play: http://play.golang.org/p/wou66vpEG3

    In the slides, Andrew made all three of the "query" methods return a
    "Result" interface. I cannot refactor my code to extract a common
    interface between my data retrieval methods because the structs have
    different fields. The only common interface is {}interface. My example
    program is also more complex because I have to deal with the query methods
    returning error.

    What do you all think about functions GetDataTwo and GetDataThree? Is one
    preferred over the other? Is there another way to solve this problem that
    I am missing?

    Luke
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 30, 2013 at 12:05 pm
    Egon,

    Thank you for posting that code. You change definitely made the program
    simpler.

    Luke
    On Friday, August 30, 2013 6:01:23 AM UTC-5, egon wrote:

    If you need all the data to do something, just use the pointers:
    http://play.golang.org/p/EL6pq2pHQa

    Although it is less "safer", it simpler and easier to read than the
    channel communication thing. If you don't need all the values at the same
    time, the channel version is probably better.

    egon
    On Thursday, August 29, 2013 10:48:25 PM UTC+3, Luke Mauldin wrote:

    All,

    I have read the "Go Concurrency Patterns" slides. I have a similar
    problem to the "Google Search" described in the slides. See the example on
    Google play: http://play.golang.org/p/wou66vpEG3

    In the slides, Andrew made all three of the "query" methods return a
    "Result" interface. I cannot refactor my code to extract a common
    interface between my data retrieval methods because the structs have
    different fields. The only common interface is {}interface. My example
    program is also more complex because I have to deal with the query methods
    returning error.

    What do you all think about functions GetDataTwo and GetDataThree? Is one
    preferred over the other? Is there another way to solve this problem that
    I am missing?

    Luke
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 30, 2013 at 12:09 pm
    Egon,

    A question, why did you use a buffered channel "chan error" instead of an
    unbuffered channel?
    On Friday, August 30, 2013 6:01:23 AM UTC-5, egon wrote:

    If you need all the data to do something, just use the pointers:
    http://play.golang.org/p/EL6pq2pHQa

    Although it is less "safer", it simpler and easier to read than the
    channel communication thing. If you don't need all the values at the same
    time, the channel version is probably better.

    egon
    On Thursday, August 29, 2013 10:48:25 PM UTC+3, Luke Mauldin wrote:

    All,

    I have read the "Go Concurrency Patterns" slides. I have a similar
    problem to the "Google Search" described in the slides. See the example on
    Google play: http://play.golang.org/p/wou66vpEG3

    In the slides, Andrew made all three of the "query" methods return a
    "Result" interface. I cannot refactor my code to extract a common
    interface between my data retrieval methods because the structs have
    different fields. The only common interface is {}interface. My example
    program is also more complex because I have to deal with the query methods
    returning error.

    What do you all think about functions GetDataTwo and GetDataThree? Is one
    preferred over the other? Is there another way to solve this problem that
    I am missing?

    Luke
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Egon at Aug 31, 2013 at 8:16 pm
    That way the goroutines sending to that channel can exit, if some error occurs (although it's even better to use some larger value). Here you can abort the function call early on first error, but with non-buffered chan, since nothing is reading from the chan the other error values the goroutines get stuck... so basically it would be a leak.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Sep 3, 2013 at 1:36 pm
    Do I need to do something else special for the goroutines to exit in the
    case of an error, or is using a buffered channel sufficient?

    Luke
    On Saturday, August 31, 2013 3:16:37 PM UTC-5, egon wrote:

    That way the goroutines sending to that channel can exit, if some error
    occurs (although it's even better to use some larger value). Here you can
    abort the function call early on first error, but with non-buffered chan,
    since nothing is reading from the chan the other error values the
    goroutines get stuck... so basically it would be a leak.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Sep 3, 2013 at 5:52 pm
    You'd need to ensure that the goroutine will exit, regardless of whether
    its values are consumed. If you use a buffered channel, you know you can
    send to it without blocking, and continue on to exit.

    On Tue, Sep 3, 2013 at 6:36 AM, Luke Mauldin wrote:

    Do I need to do something else special for the goroutines to exit in the
    case of an error, or is using a buffered channel sufficient?

    Luke

    On Saturday, August 31, 2013 3:16:37 PM UTC-5, egon wrote:

    That way the goroutines sending to that channel can exit, if some error
    occurs (although it's even better to use some larger value). Here you can
    abort the function call early on first error, but with non-buffered chan,
    since nothing is reading from the chan the other error values the
    goroutines get stuck... so basically it would be a leak.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Sep 3, 2013 at 5:55 pm
    So in this example, why create a buffered channel with a length of 1?
      Shouldn't it be with a length of 3?
    On Tuesday, September 3, 2013 12:51:26 PM UTC-5, Kyle Lemons wrote:

    You'd need to ensure that the goroutine will exit, regardless of whether
    its values are consumed. If you use a buffered channel, you know you can
    send to it without blocking, and continue on to exit.


    On Tue, Sep 3, 2013 at 6:36 AM, Luke Mauldin <lukem...@gmail.com<javascript:>
    wrote:
    Do I need to do something else special for the goroutines to exit in the
    case of an error, or is using a buffered channel sufficient?

    Luke

    On Saturday, August 31, 2013 3:16:37 PM UTC-5, egon wrote:

    That way the goroutines sending to that channel can exit, if some error
    occurs (although it's even better to use some larger value). Here you can
    abort the function call early on first error, but with non-buffered chan,
    since nothing is reading from the chan the other error values the
    goroutines get stuck... so basically it would be a leak.
    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Egon at Sep 3, 2013 at 7:00 pm
    Yes, :) made a mistake.

    egon

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 29, '13 at 7:48p
activeSep 3, '13 at 7:00p
posts9
users3
websitegolang.org

3 users in discussion

Luke Mauldin: 5 posts Egon: 3 posts Kyle Lemons: 1 post

People

Translate

site design / logo © 2021 Grokbase