FAQ
In the package net/rpc, I'm wondering why the reply is a pointer argument
and not a return value.

In other words, why do we have this:

     func (t *T) MethodName(argType T1, replyType *T2) error

instead of this:

     func (t *T) MethodName(argType T1) (*T2, error)

I'm sure there is a good reason for this, but I ignore it :)

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

  • Luna Duclos at Dec 2, 2014 at 3:55 pm
    Likely, because the rpc package uses the type of the pointer to determine
    how to deserialize it ?
    On Tue, Dec 2, 2014 at 2:41 PM, Nicolas Grilly wrote:

    In the package net/rpc, I'm wondering why the reply is a pointer argument
    and not a return value.

    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)

    I'm sure there is a good reason for this, but I ignore it :)

    --
    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.
  • Nicolas Grilly at Dec 2, 2014 at 4:18 pm

    On Tue, Dec 2, 2014 at 4:55 PM, Luna Duclos wrote:

    Likely, because the rpc package uses the type of the pointer to determine
    how to deserialize it ?
    I don't think this is the reason. The net/rpc package uses reflection, and
    reflection works on return value too. Reflection can be used to determine
    the type of the pointer, independently of the pointer being an argument or
    a return value.

    Example: http://play.golang.org/p/-DiJY7bljH

    --
    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.
  • Ian Lance Taylor at Dec 2, 2014 at 4:40 pm

    On Tue, Dec 2, 2014 at 5:41 AM, Nicolas Grilly wrote:
    In the package net/rpc, I'm wondering why the reply is a pointer argument
    and not a return value.

    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)

    I'm sure there is a good reason for this, but I ignore it :)
    I'm not sure there is a good reason. I think Rob just wrote it that
    way. That is an early package--before the open source release. He
    might have written it differently if he started it today.

    Ian

    --
    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.
  • Nicolas Grilly at Dec 2, 2014 at 6:43 pm

    On Tue, Dec 2, 2014 at 5:39 PM, Ian Lance Taylor wrote:
    On Tue, Dec 2, 2014 at 5:41 AM, Nicolas Grilly wrote:
    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)
    I'm not sure there is a good reason. I think Rob just wrote it that
    way. That is an early package--before the open source release. He
    might have written it differently if he started it today.
    Ian, thanks for your answer. Out of curiosity, if you had to rewrite
    net/rpc today, and you were not constrained by the Go 1 compatibility
    promise, would you pass the reply as an argument or as a return value?

    --
    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.
  • Ian Lance Taylor at Dec 2, 2014 at 7:07 pm

    On Tue, Dec 2, 2014 at 10:43 AM, Nicolas Grilly wrote:
    On Tue, Dec 2, 2014 at 5:39 PM, Ian Lance Taylor wrote:

    On Tue, Dec 2, 2014 at 5:41 AM, Nicolas Grilly <nicolas@vocationcity.com>
    wrote:
    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)
    I'm not sure there is a good reason. I think Rob just wrote it that
    way. That is an early package--before the open source release. He
    might have written it differently if he started it today.

    Ian, thanks for your answer. Out of curiosity, if you had to rewrite net/rpc
    today, and you were not constrained by the Go 1 compatibility promise, would
    you pass the reply as an argument or as a return value?
    Personally I would use a return value. Doesn't even have to be a
    pointer.

    Ian

    --
    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.
  • Nicolas Grilly at Dec 2, 2014 at 7:44 pm

    On Tue, Dec 2, 2014 at 8:07 PM, Ian Lance Taylor wrote:

    Personally I would use a return value. Doesn't even have to be a
    pointer.
    Yes, the return value is more straightforward and then the pointer is
    probably unnecessary. Thanks!

    I'm still wondering why Rob chose to pass the reply as an argument :)

    --
    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.
  • Bill at Dec 2, 2014 at 9:35 pm
    If you design an API around return values, it implies the functions are
    allocating, unless you do the append() trick of passing in a value and
    returning a value. If you pass the receiver in, you at least have the
    possibility of implementing a zero-allocating version.

    This is one of those things I expect isn't a pain until it bites you.

    Bill
    On 12/02, Ian Lance Taylor wrote:
    On Tue, Dec 2, 2014 at 10:43 AM, Nicolas Grilly
    wrote:
    On Tue, Dec 2, 2014 at 5:39 PM, Ian Lance Taylor wrote:

    On Tue, Dec 2, 2014 at 5:41 AM, Nicolas Grilly <nicolas@vocationcity.com>
    wrote:
    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)
    I'm not sure there is a good reason. I think Rob just wrote it that
    way. That is an early package--before the open source release. He
    might have written it differently if he started it today.

    Ian, thanks for your answer. Out of curiosity, if you had to rewrite net/rpc
    today, and you were not constrained by the Go 1 compatibility promise, would
    you pass the reply as an argument or as a return value?
    Personally I would use a return value. Doesn't even have to be a
    pointer.

    Ian

    --
    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.
  • Kostarev Ilya at Dec 2, 2014 at 10:00 pm
    I’m not assured in unix sockets case, but with TCP transport server should need allocate either way, seems.

    --Ilya

    On 3 Dec 2014 at 00:35:39, Bill (couchmoney@gmail.com) wrote:

    If you design an API around return values, it implies the functions are
    allocating, unless you do the append() trick of passing in a value and
    returning a value. If you pass the receiver in, you at least have the
    possibility of implementing a zero-allocating version.

    This is one of those things I expect isn't a pain until it bites you.

    Bill
    On 12/02, Ian Lance Taylor wrote:
    On Tue, Dec 2, 2014 at 10:43 AM, Nicolas Grilly
    wrote:
    On Tue, Dec 2, 2014 at 5:39 PM, Ian Lance Taylor wrote:

    On Tue, Dec 2, 2014 at 5:41 AM, Nicolas Grilly <nicolas@vocationcity.com>
    wrote:
    In other words, why do we have this:

    func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

    func (t *T) MethodName(argType T1) (*T2, error)
    I'm not sure there is a good reason. I think Rob just wrote it that
    way. That is an early package--before the open source release. He
    might have written it differently if he started it today.

    Ian, thanks for your answer. Out of curiosity, if you had to rewrite net/rpc
    today, and you were not constrained by the Go 1 compatibility promise, would
    you pass the reply as an argument or as a return value?
    Personally I would use a return value. Doesn't even have to be a
    pointer.

    Ian

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

    --
    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.
  • Kostarev Ilya at Dec 2, 2014 at 9:26 pm
    Type safety maybe. Client can type safely call
      err=client.Call(serviceMethod string, args knowntype1, reply knowntype2)
    Else in generic
      func (client *Client) Call(serviceMethod string, args interface{}) reply interface{}, error
    you will need for type assertion
      var reply knowntype2
      reply.(knowntype2), err=client.Call(serviceMethod string, args knowntype1)

    --
    Ilya


    On 2 Dec 2014 at 16:41:41, Nicolas Grilly (nicolas@vocationcity.com) wrote:

    In the package net/rpc, I'm wondering why the reply is a pointer argument and not a return value.

    In other words, why do we have this:

        func (t *T) MethodName(argType T1, replyType *T2) error

    instead of this:

        func (t *T) MethodName(argType T1) (*T2, error)

    I'm sure there is a good reason for this, but I ignore it :)
    --
    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.
  • Kostarev Ilya at Dec 2, 2014 at 9:39 pm
    Sorry, typo, actually even harder
    something, err=client.Call(serviceMethod string, args knowntype1)
    reply=something.(knowntype2)

    --
    Ilya


    On 3 Dec 2014 at 00:26:40, Kostarev Ilya (uvelichitel@gmail.com) wrote:

    reply.(knowntype2), err=client.Call(serviceMethod string, args knowntype1)

    --
    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.
  • Nicolas Grilly at Dec 2, 2014 at 10:03 pm
    Now I realize my initial question was not clear enough.

    My question was related to the signature of methods available for remote
    access on the **server** side.

    My question was unrelated to the signature of the method Call on the
    **client** side. I agree with Luna, Ilya and Bill: on the client side, the
    only reasonable choice is to pass the reply as a pointer argument (to avoid
    a type assertion and to optimize allocations if necessary).
    On Tue, Dec 2, 2014 at 10:26 PM, Kostarev Ilya wrote:

    Type safety maybe. Client can type safely call
    err=client.Call(serviceMethod string, args knowntype1, reply knowntype2)
    Else in generic
    func (client *Client) Call(serviceMethod string, args interface{}) reply
    interface{}, error
    you will need for type assertion
    var reply knowntype2
    reply.(knowntype2), err=client.Call(serviceMethod string, args knowntype1)
    --
    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.
  • Rob Pike at Dec 2, 2014 at 10:13 pm
    That package was written long ago and with a different implementation of
    reflection. I believe the technical reason was getting a settable object
    that the library could assign a value. Even today, I think a pointer makes
    it easier.

    But honestly I believe I was just following a pattern I'd seen before.

    -rob

    --
    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.
  • Nicolas Grilly at Dec 3, 2014 at 7:27 pm

    On Tue, Dec 2, 2014 at 11:12 PM, Rob Pike wrote:

    That package was written long ago and with a different implementation of
    reflection. I believe the technical reason was getting a settable object
    that the library could assign a value. Even today, I think a pointer makes
    it easier.

    But honestly I believe I was just following a pattern I'd seen before.
    Thanks Rob for the insights. I'm working on a similar problem for a REST
    router. This is the reason why I was asking.

    --
    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
postedDec 2, '14 at 1:41p
activeDec 3, '14 at 7:27p
posts14
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase