FAQ
In "Go design question regarding growing interfaces<https://groups.google.com/d/msg/golang-nuts/mliXGIRUu80/20eJ5egM8mUJ>"
I was puzzled by not seeing channels mentioned. An excerpt:

The interface system in Go is elaborate, but in the examples I don't see
channels being used. Contrary, in the channels description at
http://golang.org/doc/effective_go.html#channels (especially the
"Channels of channels") - doesn't it also describe a kind of interface
system? Since channels are typed, just adding a new value in its struct and
code for it adds functionality. In the "Interfaces" chapter of the same
page there are "Methods required by sort.Interface." Why couldn't that be
"channel ends required by sort.gorotine"?

Do I smell first-class channels getting to ride in the interface back seat
just because the world's interface thinking is method based?

Could somebody "sort out" (pun intended) the difference between
interface-based interfaces and channel-based interfaces? (Or don't the
latter exist?)

(There was a comment to this at the mentioned thread)

Øyvind Teig

--
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

  • Jsor at Dec 18, 2013 at 12:12 pm
    From a pure usefulness and conceptual standpoint I could certainly see an
    argument for something like

    type Router interface {
         InChan chan<- int
         RegisterResponseChan(chan<- int)
    }

    I think the question becomes a bit messy, though:

    Channels are variables, and interfaces would then need to look at a
    struct's variables. Function variables already do not satisfy interfaces,
    adding this is possible, but it does force us to address certain questions
    like: the zero value for a function is nil, does the function still satisfy
    the interface if its function is nil? If so, is letting interfaces not have
    functions okay? Obviously a call to an interface function can already
    panic, but do we want to allow that to be default behavior? How many steps
    away is this from making interfaces abstract classes -- where we can also
    assure you that a struct has an exposed Int field named "X"?

    Okay, so let's say we make channels a super-first-class feature. Like, you
    can declare them with a receiver and everything. How would this work? Would
    each defined channel have its own goroutine that launched when the object
    was built? Can you close such a channel? The best I can see is forcing all
    of them to have some sort of Start method, so when I make a new channel it
    auto-calls this:

    func (r *MyRouter) Start() {
         for i := range InChan {
             getRegisteredResponseChan() <- i
         }
    }

    But that's getting pretty close to constructor territory. In general, it
    just adds a lot of complications to the lifecycle of a struct or interface,
    especially the birth. One of the biggest problems is that it will never be
    GC'd until the channel is closed, which is what happens now, except closing
    it early also means it won't adequately satisfy any interface that requires
    it to have an open channel. There's a lot of potential gotchas there, and
    confusing situations where references may still be around, but it doesn't
    technically satisfy the interface it promises to. You could make an
    argument that the channel could be nil, closed, or whatever else, but then
    how is that any different from this:

    type Router interface {
         InChan() chan<- int
    }

    Overall, I like the *idea* of allowing channeled interfaces, but I'm not
    sure it's practical given that you can pretty much duplicate the same
    functionality without any major philosophical questions with functions.
    On Wednesday, December 18, 2013 4:28:40 AM UTC-7, Øyvind Teig wrote:

    In "Go design question regarding growing interfaces<https://groups.google.com/d/msg/golang-nuts/mliXGIRUu80/20eJ5egM8mUJ>"
    I was puzzled by not seeing channels mentioned. An excerpt:

    The interface system in Go is elaborate, but in the examples I don't see
    channels being used. Contrary, in the channels description at
    http://golang.org/doc/effective_go.html#channels (especially the
    "Channels of channels") - doesn't it also describe a kind of interface
    system? Since channels are typed, just adding a new value in its struct and
    code for it adds functionality. In the "Interfaces" chapter of the same
    page there are "Methods required by sort.Interface." Why couldn't that be
    "channel ends required by sort.gorotine"?

    Do I smell first-class channels getting to ride in the interface back
    seat just because the world's interface thinking is method based?

    Could somebody "sort out" (pun intended) the difference between
    interface-based interfaces and channel-based interfaces? (Or don't the
    latter exist?)

    (There was a comment to this at the mentioned thread)

    Øyvind Teig
    --
    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.
  • Øyvind Teig at Dec 18, 2013 at 1:14 pm
    Thank for the stretch! Please stop me if I'm wrong in my comments:

    kl. 13:12:29 UTC+1 onsdag 18. desember 2013 skrev Jsor følgende:
    From a pure usefulness and conceptual standpoint I could certainly see an
    argument for something like
    type Router interface {
    InChan chan<- int
    RegisterResponseChan(chan<- int)
    }
    I think the question becomes a bit messy, though:
    Channels are variables,
    I would think that they are keys to shared data. Which means they are
    "thread safe" (with no usage checks in Go, you'd have to use them
    correctly).

    and interfaces would then need to look at a struct's variables.
    Looking at that struct would mean to look into communicated values

    Function variables already do not satisfy interfaces,
    I was thinking that a channel-based interface is channel based only. Period.

    adding this is possible, but it does force us to address certain
    questions like: the zero value for a function is nil, does the function
    still satisfy the interface if its function is nil? If so, is letting
    interfaces not have functions okay? Obviously a call to an interface
    function can already panic, but do we want to allow that to be default
    behavior? How many steps away is this from making interfaces abstract
    classes -- where we can also assure you that a struct has an exposed Int
    field named "X"?
    I am not certain if we need to address nil channels. If we wanted to do a
    subscription over a channel interface, both the input channel and the
    subscribed to (f.ex second ticks) channel would be valid. Also, I have
    believed that since channels are (statically?) typed it's either illegal or
    not possible to listen or send on a wrongly typed channel. Is it possible
    to have anonymous channels? Anyhow the contents inside a legal channel
    struct could be mismatched, and that needs to be returned on the return
    channel as invalid. I wouldn't think this is up to the language, as the Go
    already acknowledges: no direct exception
    Okay, so let's say we make channels a super-first-class feature. Like,
    you can declare them with a receiver and everything. How would this work?
    Would each defined channel have its own goroutine that launched when the
    object was built? Can you close such a channel? The best I can see is
    forcing all of them to have some sort of Start method, so when I make a new
    channel it auto-calls this
    func (r *MyRouter) Start() {
    for i := range InChan {
    getRegisteredResponseChan() <- i
    }
    }
    There is no direct connection between a channel and the users of it. In the
    most difficult case the receiver is at the other end of a remote socket.
    Like we have to "make" channels, we have to "start" gorotines by hand when
    we want them. That's the paradigm(?)

    But that's getting pretty close to constructor territory. In general, it
    just adds a lot of complications to the lifecycle of a struct or interface,
    especially the birth. One of the biggest problems is that it will never be
    GC'd until the channel is closed, which is what happens now, except closing
    it early also means it won't adequately satisfy any interface that requires
    it to have an open channel. There's a lot of potential gotchas there, and
    confusing situations where references may still be around, but it doesn't
    technically satisfy the interface it promises to. You could make an
    argument that the channel could be nil, closed, or whatever else, but then
    how is that any different from this:
    type Router interface {
    InChan() chan<- int
    }
    Why be more concerned about GC of channels than any other object in need of
    garbage collection? Why should channels be in a special situation? If this
    had been so, the Go designers would have made channels all static(?) But
    they didn't.
    Overall, I like the *idea* of allowing channeled interfaces, but I'm not
    sure it's practical given that you can pretty much duplicate the same
    functionality without any major philosophical questions with functions.
    I am not certain if you *really* made your channels *super*-first-class
    feature! I like the name, because they don't seem to be now. But is it the
    language or our use of it that make them non-super? Aren't much of the
    philosophical questions resolved by the CSP thinking already?

    Øyvind

    --
    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
postedDec 18, '13 at 11:28a
activeDec 18, '13 at 1:14p
posts3
users2
websitegolang.org

2 users in discussion

Øyvind Teig: 2 posts Jsor: 1 post

People

Translate

site design / logo © 2021 Grokbase