FAQ
Why is it not allowed to define pointer types as named types with methods?

It is possible to fake this using unsafe.Pointer (see
http://play.golang.org/p/Iz35o8mqdy ), so I wonder why.

(Background: I was trying to see if I coulud cover up some of my API
mistakes in the SSH package by defining the NewChannel and Channel
types as pointers rather than interfaces)

--

Google Germany GmbH, Dienerstrasse 12, 80331 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

  • Chris Manghane at Jun 9, 2015 at 1:25 pm
    From http://golang.org/ref/spec#Method_declarations:
    "The type denoted by T is called the receiver base type; it must not be a
    pointer or interface type and it must be declared in the same package as
    the method."

    I'm not sure what you're trying to do here, but it seems like you could
    accomplish it by making `type pt int` and then defining f on the pointer
    receiver *pt. That seems like the same thing as defining a receiver type as
    a pointer type with its methods.
    On Tue, Jun 9, 2015 at 3:02 AM 'Han-Wen Nienhuys' via golang-nuts wrote:

    Why is it not allowed to define pointer types as named types with methods?

    It is possible to fake this using unsafe.Pointer (see
    http://play.golang.org/p/Iz35o8mqdy ), so I wonder why.

    (Background: I was trying to see if I coulud cover up some of my API
    mistakes in the SSH package by defining the NewChannel and Channel
    types as pointers rather than interfaces)

    --

    Google Germany GmbH, Dienerstrasse 12, 80331 Munich

    Registergericht und -nummer: Hamburg, HRB 86891

    Sitz der Gesellschaft: Hamburg

    Geschäftsführer: Graham Law, Christine Elizabeth Flores

    --
    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.
  • Han-Wen Nienhuys at Jun 9, 2015 at 1:38 pm
    n
    On Tue, Jun 9, 2015 at 3:25 PM, Chris Manghane wrote:
    From http://golang.org/ref/spec#Method_declarations:
    "The type denoted by T is called the receiver base type; it must not be a
    pointer or interface type and it must be declared in the same package as the
    method."
    Sure, I found that reference. I'm curious *why* pointers are forbidden.
    I'm not sure what you're trying to do here, but it seems like you could
    accomplish it by making `type pt int` and then defining f on the pointer
    receiver *pt. That seems like the same thing as defining a receiver type as
    a pointer type with its methods.
    I have code that looks like

       type Channel interface { .. }
       func New() Channel { .. }

    In this case, the Channel isn't really an interface (there is only one
    implementation of it), and suggests that we will never add new methods
    to the type. If I could convert this to

       type Channel *impl
       func New() Channel { .. }

    then this gives us more freedom for adding methods to Channel, without
    breaking the bulk of the existing callers. By contrast, saying

       type Channel struct { .. }
       func New() *Channel

    will break type declarations in callers of the API.

    I realize aliasing Channel to a poniter may not be desirable for other
    reasons, but that is beside the point here.

    On Tue, Jun 9, 2015 at 3:02 AM 'Han-Wen Nienhuys' via golang-nuts
    wrote:
    Why is it not allowed to define pointer types as named types with methods?

    It is possible to fake this using unsafe.Pointer (see
    http://play.golang.org/p/Iz35o8mqdy ), so I wonder why.

    (Background: I was trying to see if I coulud cover up some of my API
    mistakes in the SSH package by defining the NewChannel and Channel
    types as pointers rather than interfaces)

    --

    Google Germany GmbH, Dienerstrasse 12, 80331 Munich

    Registergericht und -nummer: Hamburg, HRB 86891

    Sitz der Gesellschaft: Hamburg

    Geschäftsführer: Graham Law, Christine Elizabeth Flores

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


    --
    Han-Wen Nienhuys
    Google Munich
    hanwen@google.com

    --
    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 Jun 9, 2015 at 2:24 pm

    On Tue, Jun 9, 2015 at 3:01 AM, 'Han-Wen Nienhuys' via golang-nuts wrote:

    Why is it not allowed to define pointer types as named types with methods?
    Because in a case like this:

    type I int
    type P *I
    func (i I) Get() int { return int(i) }
    func (p P) Get() int { return int(*p) }
    var v I
    var x = (&v).Get()

    it would be unclear whether the Get method in the last line would be
    I.Get or P.Get. We could define a rule for it, but that would become
    another thing that people would have to know.

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 9, '15 at 10:01a
activeJun 9, '15 at 2:24p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase