5 ms·

OnHtml callbacks? Not a big fan of callbacks when you have channels.

• asciimoo 9y ago
  Interesting idea, how do you imagine a channel based API for this?
  • JoeAcchino 9y ago
    Would this work? c := colly.NewCollector() // this functions create a goroutine and returns a channel ch := c.HTML("a") e := <- ch link := e.Attr("href") // ... I'm a bit rusty (ah!) with go, so bear with me if the above contains errors.
    • maxpert 9y ago
      This would work. No callback hell a pleasure for eyes!
    • asciimoo 9y ago
      How do you recognize if the collector has finished? If the site doesn't contain "a" elements (e.g. because of a network error), this example would block forever.
      • dward 9y ago
        The producer closes the channel. This is differentiable from an open empty channel in a select.
        • asciimoo 9y ago
          Makes sense, thanks =) In the above example this would require `nil` checking of the retrieved value every time. I'm not sure if it would make the API cleaner
  • hellcow 9y ago
    I would ignore the GP's advice. Channels are prone to big errors -- panics and blocking -- which aren't detectable at compile time. They make sense to use internally but shouldn't be exposed in a public API. As one example, notice how the standard library's net/http package doesn't require you to use channels, but it uses them internally.
• weberc2 9y ago
  Channels require concurrency; you have to spin up another goroutine and take care not to let or deadlock. Channels are for communication between goroutines, not for general abstraction.
  • hnlmorg 9y ago
    I agree. Callbacks makes sense in this context and is the idiomatic way to write the code given that's the approach used in the standard library. eg: https://golang.org/pkg/path/filepath/#Walk https://golang.org/pkg/path/filepath/#Walk https://golang.org/pkg/net/http/#HandleFunc https://golang.org/pkg/net/http/#HandleFunc
  • weberc2 9y ago
    *Take care not to leak or deadlock