FAQ
Greetings,

http://play.golang.org/p/f9SeGTScPO - can I somehow create a method common
for 5 types so that this method has access to X field (that all types have)
and I don't have to copy the same code 5 times?

Cheers
Eugene

--
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/d/optout.

Search Discussions

  • Caleb Spare at Jul 8, 2014 at 7:21 pm
    You can use an embedded field:

    http://play.golang.org/p/DekFRYqESE

    On Tue, Jul 8, 2014 at 12:18 PM, Eugene Toropov
    wrote:
    Greetings,

    http://play.golang.org/p/f9SeGTScPO - can I somehow create a method common
    for 5 types so that this method has access to X field (that all types have)
    and I don't have to copy the same code 5 times?

    Cheers
    Eugene

    --
    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/d/optout.
    --
    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/d/optout.
  • Eugene Toropov at Jul 8, 2014 at 7:26 pm
    Cool, thanks a lot!
    On Tuesday, July 8, 2014 11:22:10 PM UTC+4, Caleb Spare wrote:

    You can use an embedded field:

    http://play.golang.org/p/DekFRYqESE
    --
    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/d/optout.
  • Steve McCoy at Jul 8, 2014 at 7:23 pm
    Either use runtime reflection (http://golang.org/pkg/reflect/) or use a
    program to write the code for you.

    On Tuesday, July 8, 2014 3:18:55 PM UTC-4, Eugene Toropov wrote:

    Greetings,

    http://play.golang.org/p/f9SeGTScPO - can I somehow create a method
    common for 5 types so that this method has access to X field (that all
    types have) and I don't have to copy the same code 5 times?

    Cheers
    Eugene
    --
    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/d/optout.
  • Egon at Jul 8, 2014 at 8:06 pm

    On Tuesday, 8 July 2014 22:18:55 UTC+3, Eugene Toropov wrote:
    Greetings,

    http://play.golang.org/p/f9SeGTScPO - can I somehow create a method
    common for 5 types so that this method has access to X field (that all
    types have) and I don't have to copy the same code 5 times?
    This problem can be caused by poor modeling, what is the actual code where
    you are having the problem <https://code.google.com/p/go-wiki/wiki/HowToAsk>
    .
    One possible solution is embedding, but there can be other solutions that
    work better.

    + 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/d/optout.
  • Val at Jul 9, 2014 at 10:04 am
    Hi Eugene
    This looks to me like a perfect use case for an Interface :
    http://play.golang.org/p/TdXR5txCnj
    as you basically want different types to share a common feature (i.e
    providing value X) and write functions (e.g. xPlusOne()) which take any of
    these types indifferently.
    Pointer receivers are not mandatory, but usually preferable.
    Best regards
    Valentin
    On Tuesday, July 8, 2014 9:18:55 PM UTC+2, Eugene Toropov wrote:

    Greetings,

    http://play.golang.org/p/f9SeGTScPO - can I somehow create a method
    common for 5 types so that this method has access to X field (that all
    types have) and I don't have to copy the same code 5 times?

    Cheers
    Eugene
    --
    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/d/optout.
  • Eugene Toropov at Jul 9, 2014 at 10:14 am
    Hi Valentin,

    No, it’s not unfortunately. In your example I’d have to create GetX method
    for each type while I needed it created once for all types. In my real
    example those types implement a number of interfaces but still there are
    methods that they must share and the only way to do it is embedded type
    including all common fields and methods.

    Cheers

    Eugene

    --
    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/d/optout.
  • Val at Jul 9, 2014 at 11:11 am
    Eugene, the number of getters (and probably setters) to create is strictly
    the same as the number of times field X was declared in the first place so
    there is no uncontrolled bloat here, and then it does let you write
    "generic" functions for type Xer. You don't have to write 5 times each new
    function. According to me this is the prefered Go OO-like way to achieve
    this kind of genericity.

    Embedding-based solutions are also fine and have less boilerplate, but then
    you are more closely coupled to the internal details of your embedded type
    hierarchy.
    On Wednesday, July 9, 2014 12:14:21 PM UTC+2, Eugene Toropov wrote:

    Hi Valentin,

    No, it’s not unfortunately. In your example I’d have to create GetX method
    for each type
    --
    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/d/optout.
  • Eugene Toropov at Jul 9, 2014 at 11:30 am
    " it does let you write "generic" functions for type Xer" - interface can't
    be method receiver according
    to http://golang.org/ref/spec#Method_declarations

    So I can't declare method once for Xer type so that it becomes available
    for all the rest 5 types. Please let me know if I don't udnerstand something

    Cheers
    Eugene

    --
    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/d/optout.
  • Val at Jul 9, 2014 at 12:16 pm
    Indeed, type Xer cannot be the method receiver, so it has to be a method
    argument.

    I agree it looks more "procedural" than OO but it still achieves
    polymorphism (we don't have to care about the underlying type of the
    object, as long as it implements Xer) and it still avoids to duplicate
    methods again and again.
    On Wednesday, July 9, 2014 1:30:20 PM UTC+2, Eugene Toropov wrote:

    " it does let you write "generic" functions for type Xer" - interface
    can't be method receiver according to
    http://golang.org/ref/spec#Method_declarations

    So I can't declare method once for Xer type so that it becomes available
    for all the rest 5 types. Please let me know if I don't udnerstand something

    Cheers
    Eugene
    --
    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/d/optout.
  • Eugene Toropov at Jul 9, 2014 at 12:36 pm
    Sorry, but I don't feel it's a good way and of course it's not a Go way.
    Unless you can show me where it's done this way on github of course.
    On Wednesday, July 9, 2014 4:16:51 PM UTC+4, Val wrote:

    Indeed, type Xer cannot be the method receiver, so it has to be a method
    argument.

    I agree it looks more "procedural" than OO but it still achieves
    polymorphism (we don't have to care about the underlying type of the
    object, as long as it implements Xer) and it still avoids to duplicate
    methods again and again.
    --
    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/d/optout.
  • Val at Jul 9, 2014 at 1:19 pm
    That's the way the sort package works, regarding most of your concerns :
    - data containers are not receiver of method Sort
    - method Sort expect the data container as argument, which must implement
    sort.Interface
    - clients must implement methods Len,Less,Swap for each different container
    type
    - sort algorithm is written only in package sort, not for each type to be
    sorted
    - no embedding needed

    Whether this must be regarded as elegant or not was not my point, I say
    this is among the idiomatic go practices because a well-informed gopher
    told me : generics are not a missing feature, interfaces are the generics.
    On Wednesday, July 9, 2014 2:36:06 PM UTC+2, Eugene Toropov wrote:

    Sorry, but I don't feel it's a good way and of course it's not a Go way.
    Unless you can show me where it's done this way on github of course.
    On Wednesday, July 9, 2014 4:16:51 PM UTC+4, Val wrote:

    Indeed, type Xer cannot be the method receiver, so it has to be a method
    argument.

    I agree it looks more "procedural" than OO but it still achieves
    polymorphism (we don't have to care about the underlying type of the
    object, as long as it implements Xer) and it still avoids to duplicate
    methods again and again.
    --
    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/d/optout.
  • Eugene Toropov at Jul 9, 2014 at 1:26 pm
    Thanks. I'll look into sort package when have a moment.
    On Wednesday, July 9, 2014 5:19:44 PM UTC+4, Val wrote:

    That's the way the sort package works, regarding most of your concerns :
    - data containers are not receiver of method Sort
    - method Sort expect the data container as argument, which must implement
    sort.Interface
    - clients must implement methods Len,Less,Swap for each different
    container type
    - sort algorithm is written only in package sort, not for each type to be
    sorted
    - no embedding needed

    Whether this must be regarded as elegant or not was not my point, I say
    this is among the idiomatic go practices because a well-informed gopher
    told me : generics are not a missing feature, interfaces are the generics.
    On Wednesday, July 9, 2014 2:36:06 PM UTC+2, Eugene Toropov wrote:

    Sorry, but I don't feel it's a good way and of course it's not a Go way.
    Unless you can show me where it's done this way on github of course.
    On Wednesday, July 9, 2014 4:16:51 PM UTC+4, Val wrote:

    Indeed, type Xer cannot be the method receiver, so it has to be a method
    argument.

    I agree it looks more "procedural" than OO but it still achieves
    polymorphism (we don't have to care about the underlying type of the
    object, as long as it implements Xer) and it still avoids to duplicate
    methods again and again.
    --
    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/d/optout.
  • Jan Mercl at Jul 9, 2014 at 10:28 am

    On Tue, Jul 8, 2014 at 9:18 PM, Eugene Toropov wrote:
    http://play.golang.org/p/f9SeGTScPO - can I somehow create a method common
    for 5 types so that this method has access to X field (that all types have)
    and I don't have to copy the same code 5 times?
    http://play.golang.org/p/nVWxXbQsU4 ?

    -j

    --
    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/d/optout.
  • Eugene Toropov at Jul 9, 2014 at 10:37 am
    Hi Jan,

    Yeah, I actually implemented something similar already as Caleb above
    already pointed the right direction. But thanks for help anyway.

    Cheers
    Eugene


    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 8, '14 at 7:19p
activeJul 9, '14 at 1:26p
posts15
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase