5 ms·

Reminds me of Java's use of listener objects because it lacked (at the time) lambdas and method references for callbacks. Hopefully Go generics continue to imp

by jayd16 5y ago

Reminds me of Java's use of listener objects because it lacked (at the time) lambdas and method references for callbacks. Hopefully Go generics continue to improve.

kubb 5y ago
I wonder if the limitation of not allowing type parameters for methods came from wanting to prevent people from using it for certain features that would be considered "too complicated for Go", or from it being "too complicated to support" or from "we won't be needing it anyways". Another option to circumvent this is to use top-level functions, and accept the receiver as the first argument of the function. This is effectively the same thing, the only thing it's missing is the object.method() syntax that's familiar to OO programmers.
- randomdata 5y ago
  No need to wonder. The proposal goes into lengthy detail as to why they are not included. There is hope that they will be added in the future, but solutions to the problems will need to be found first.
  - kubb 5y ago
    I wouldn't call it lengthy, but if anyone is wondering, the proposal points out that parametrized methods don't have an obvious behavior _inside interfaces_. No mention of why they left them out in non-interface types.
    - Ericson2314 5y ago
      Yeah they are just being ignorant once again. Even "static" interface usage, a la Rust Traits, is fine. But Go doesn't distinguish between the static stuff and the dynamic vtable stuff very well at all. That's the problem they should fix.
      - randomdata 5y ago
        > Yeah they are just being ignorant once again. That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept. It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.
        saghm 5y ago
        It seems plausible that some people who might otherwise want to have decided not to given the very vocal contingent of the Go community that's been opposed to generics. After almost a decade of people saying Go didn't need generics, it seems like it would be hard to convince people who are knowledgeable in that field that their efforts would be welcome.
        randomdata 5y ago
        The core Go team has been working on generics since the pre-1.0 days and have submitted many different generics proposals over the years to reflect that. They all, until the latest one, failed for one reason or another, but shared property of them all was being created by those who were not experts in the domain. It is why the latest incarnation brought in an external consultant to help guide the team in the right direction. There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.
        andrekandre 5y ago
        what is the major difference of go generics vs say c# or swift generics that makes the long wait worth it for go? was there any major breakthroughs?
    - mseepgood 5y ago
      In Go any type can implement interfaces. A type doesn't declare which interfaces it implements.
      - masklinn 5y ago
        That doesn't seem like a relevant objection? If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement. The reverse would be an issue, but this is not.
    - crtc 5y ago
      > No mention of why they left them out in non-interface types. Actually it does: "Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function." https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
      - erik_seaberg 5y ago
        Except that reflection-based tools work with methods but not functions.
        crtc 5y ago
        Yes, but reflection is part of the problem: "And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable." So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.
mcculley 5y ago
I don’t think I understand what you mean. What would have been different about listener interfaces if lambdas and method references had been available?
- jayd16 5y ago
  Some examples here show the difference: https://stackoverflow.com/questions/4685563/how-to-pass-a-function-as-a-parameter-in-java https://stackoverflow.com/questions/4685563/how-to-pass-a-fu... addCallback(new Callable<Integer>() { public Integer call() { return callback(); } }); vs addCallback(this::callback); At least anonymous types meant you didn't have to manually name all your listener boilerplate.
  - mcculley 5y ago
    Ah. Yeah, this would have made callbacks simpler in the case where there is only one method. I was thinking about JavaBeans EventObject/EventListener usage, which is so tedious, but enables introspection by tools.

by jayd16 5y ago

Reminds me of Java's use of listener objects because it lacked (at the time) lambdas and method references for callbacks. Hopefully Go generics continue to improve.

kubb 5y ago

I wonder if the limitation of not allowing type parameters for methods came from wanting to prevent people from using it for certain features that would be considered "too complicated for Go", or from it being "too complicated to support" or from "we won't be needing it anyways". Another option to circumvent this is to use top-level functions, and accept the receiver as the first argument of the function. This is effectively the same thing, the only thing it's missing is the object.method() syntax that's familiar to OO programmers.

randomdata 5y ago
No need to wonder. The proposal goes into lengthy detail as to why they are not included. There is hope that they will be added in the future, but solutions to the problems will need to be found first.
- kubb 5y ago
  I wouldn't call it lengthy, but if anyone is wondering, the proposal points out that parametrized methods don't have an obvious behavior _inside interfaces_. No mention of why they left them out in non-interface types.
  - Ericson2314 5y ago
    Yeah they are just being ignorant once again. Even "static" interface usage, a la Rust Traits, is fine. But Go doesn't distinguish between the static stuff and the dynamic vtable stuff very well at all. That's the problem they should fix.
    - randomdata 5y ago
      > Yeah they are just being ignorant once again. That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept. It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.
      - saghm 5y ago
        It seems plausible that some people who might otherwise want to have decided not to given the very vocal contingent of the Go community that's been opposed to generics. After almost a decade of people saying Go didn't need generics, it seems like it would be hard to convince people who are knowledgeable in that field that their efforts would be welcome.
        randomdata 5y ago
        The core Go team has been working on generics since the pre-1.0 days and have submitted many different generics proposals over the years to reflect that. They all, until the latest one, failed for one reason or another, but shared property of them all was being created by those who were not experts in the domain. It is why the latest incarnation brought in an external consultant to help guide the team in the right direction. There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.
        andrekandre 5y ago
        what is the major difference of go generics vs say c# or swift generics that makes the long wait worth it for go? was there any major breakthroughs?
  - mseepgood 5y ago
    In Go any type can implement interfaces. A type doesn't declare which interfaces it implements.
    - masklinn 5y ago
      That doesn't seem like a relevant objection? If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement. The reverse would be an issue, but this is not.
  - crtc 5y ago
    > No mention of why they left them out in non-interface types. Actually it does: "Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function." https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
    - erik_seaberg 5y ago
      Except that reflection-based tools work with methods but not functions.
      - crtc 5y ago
        Yes, but reflection is part of the problem: "And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable." So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.

mcculley 5y ago

I don’t think I understand what you mean. What would have been different about listener interfaces if lambdas and method references had been available?

jayd16 5y ago
Some examples here show the difference: https://stackoverflow.com/questions/4685563/how-to-pass-a-function-as-a-parameter-in-java https://stackoverflow.com/questions/4685563/how-to-pass-a-fu... addCallback(new Callable<Integer>() { public Integer call() { return callback(); } }); vs addCallback(this::callback); At least anonymous types meant you didn't have to manually name all your listener boilerplate.
- mcculley 5y ago
  Ah. Yeah, this would have made callbacks simpler in the case where there is only one method. I was thinking about JavaBeans EventObject/EventListener usage, which is so tedious, but enables introspection by tools.