FAQ
I am trying to do the following but it des not compile (
http://play.golang.org/p/HTWEQ98MPZ):

package main

import "fmt"

type Stack *[]int
func (s Stack) Push(e int) { *s = append(*s, e) }
func (s Stack) Top() int { return (*s)[len(*s)-1] }
func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

func main() {
     var s Stack = &[]int{}
     s.Push(1)
     s.Push(2)
     s.Push(3)
     fmt.Println(s.Pop())
     fmt.Println(s.Pop())
     fmt.Println(s.Pop())
}

Nor does this work (http://play.golang.org/p/11hX3oRnIU):

package main

import "fmt"

type ConcretStack []int
type Stack *ConcretStack
func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

func main() {
     var s Stack = &ConcretStack{}
     s.Push(1)
     s.Push(2)
     s.Push(3)
     fmt.Println(s.Pop())
     fmt.Println(s.Pop())
     fmt.Println(s.Pop())
}

Does any one have some ideas on this?

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

  • Rob Pike at Oct 9, 2014 at 9:18 pm
    You can't define a method on a pointer type. And you don't need to. Use

    type Stack []int

    and define the methods on *Stack.
    On Thu, Oct 9, 2014 at 2:06 PM, xingtao zhao wrote:
    I am trying to do the following but it des not compile
    (http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?

    --
    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.
  • Xingtao zhao at Oct 9, 2014 at 9:47 pm
    OK, then my question is: why we can not define a method on a pointer type?

    The reason that I want to do that is: I am defining some algorithm which is
    working on some interface:
    package algorithm
    import p "stack_interface"
    func some_algorithm(c p.Stack) { .. }

    package stack_interface
    type Stack interface {
         Push(e int)
         Top() int
         Pop()
    }

    package stack
    type ConcretStack []int
    type Stack *ConcretStack
    ... // define Push, Top, and Pop

    If I want to remove the one layer of abstraction, I could simply replace
    the import line in package algorithm from `import p "stack_interface"` to
    `import p "stack"`, and do not need to replace all of the "Stack"s in
    algorithm with "* Stack"s.

    The usecase might not be that important.

    But I am just confused by that it is forbidden to define methods on named
    pointer types, but allowed to define methods on unnamed pointer types.
    What's the underneath reason for this design?

    Thanks!
    On Thursday, October 9, 2014 2:18:34 PM UTC-7, Rob 'Commander' Pike wrote:

    You can't define a method on a pointer type. And you don't need to. Use

    type Stack []int

    and define the methods on *Stack.

    On Thu, Oct 9, 2014 at 2:06 PM, xingtao zhao <zhaox...@gmail.com
    <javascript:>> wrote:
    I am trying to do the following but it des not compile
    (http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?

    --
    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...@googlegroups.com <javascript:>.
    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.
  • Ian Lance Taylor at Oct 9, 2014 at 9:52 pm

    On Thu, Oct 9, 2014 at 2:47 PM, xingtao zhao wrote:
    OK, then my question is: why we can not define a method on a pointer type?
    Because when you write p.M(), if p is a pointer to a type with a
    method M, p is automatically dereferenced. If we permit named pointer
    types to have methods, then it could be the case that p is a named
    pointer type with a method M and the type to which p points also has a
    method M. It is now unclear which method M will be called. Of course
    we could make up a rule to cover this situation, but that becomes
    another rule that people have to remember when looking at code. It
    seemed simpler to ban methods on named pointer types, as they are
    never necessary.

    The reason that I want to do that is: I am defining some algorithm which is
    working on some interface:
    package algorithm
    import p "stack_interface"
    func some_algorithm(c p.Stack) { .. }

    package stack_interface
    type Stack interface {
    Push(e int)
    Top() int
    Pop()
    }

    package stack
    type ConcretStack []int
    type Stack *ConcretStack
    ... // define Push, Top, and Pop

    If I want to remove the one layer of abstraction, I could simply replace the
    import line in package algorithm from `import p "stack_interface"` to
    `import p "stack"`, and do not need to replace all of the "Stack"s in
    algorithm with "* Stack"s.

    The usecase might not be that important.
    You can do this by writing

    type Stack struct {
         *ConcreteStack
    }
    // Define Push, Top, and Pop on Stack.

    Now everything should work.

    That said, it's quite unusual to use a pointer to a slice, so I would
    just write

    type Stack []int

    Why do you want to use a pointer to a slice? A slice is already a
    small value. For a case like this using a pointer adds nothing.

    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.
  • Xingtao zhao at Oct 9, 2014 at 10:15 pm

    On Thursday, October 9, 2014 2:53:02 PM UTC-7, Ian Lance Taylor wrote:
    On Thu, Oct 9, 2014 at 2:47 PM, xingtao zhao <zhaox...@gmail.com
    <javascript:>> wrote:
    OK, then my question is: why we can not define a method on a pointer
    type?

    Because when you write p.M(), if p is a pointer to a type with a
    method M, p is automatically dereferenced. If we permit named pointer
    types to have methods, then it could be the case that p is a named
    pointer type with a method M and the type to which p points also has a
    method M. It is now unclear which method M will be called. Of course
    we could make up a rule to cover this situation, but that becomes
    another rule that people have to remember when looking at code. It
    seemed simpler to ban methods on named pointer types, as they are
    never necessary.
    This is not true. As in my second example:
    http://play.golang.org/p/11hX3oRnIU, no methods are defined on Stack. Thus
    there is no ambiguous here at all.

    The reason that I want to do that is: I am defining some algorithm which is
    working on some interface:
    package algorithm
    import p "stack_interface"
    func some_algorithm(c p.Stack) { .. }

    package stack_interface
    type Stack interface {
    Push(e int)
    Top() int
    Pop()
    }

    package stack
    type ConcretStack []int
    type Stack *ConcretStack
    ... // define Push, Top, and Pop

    If I want to remove the one layer of abstraction, I could simply replace the
    import line in package algorithm from `import p "stack_interface"` to
    `import p "stack"`, and do not need to replace all of the "Stack"s in
    algorithm with "* Stack"s.

    The usecase might not be that important.
    You can do this by writing

    type Stack struct {
    *ConcreteStack
    }
    // Define Push, Top, and Pop on Stack.
    Now everything should work.
    Thanks! This is the way I could thought to solve the problem as well.
    That said, it's quite unusual to use a pointer to a slice, so I would
    just write

    type Stack []int

    Why do you want to use a pointer to a slice? A slice is already a
    small value. For a case like this using a pointer adds nothing.

    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.
  • Ian Lance Taylor at Oct 9, 2014 at 10:30 pm

    On Thu, Oct 9, 2014 at 3:15 PM, xingtao zhao wrote:
    On Thursday, October 9, 2014 2:53:02 PM UTC-7, Ian Lance Taylor wrote:
    On Thu, Oct 9, 2014 at 2:47 PM, xingtao zhao wrote:

    OK, then my question is: why we can not define a method on a pointer
    type?
    Because when you write p.M(), if p is a pointer to a type with a
    method M, p is automatically dereferenced. If we permit named pointer
    types to have methods, then it could be the case that p is a named
    pointer type with a method M and the type to which p points also has a
    method M. It is now unclear which method M will be called. Of course
    we could make up a rule to cover this situation, but that becomes
    another rule that people have to remember when looking at code. It
    seemed simpler to ban methods on named pointer types, as they are
    never necessary.

    This is not true. As in my second example:
    http://play.golang.org/p/11hX3oRnIU, no methods are defined on Stack. Thus
    there is no ambiguous here at all.
    Sorry, I understand that your specific case is not ambiguous. What I
    was trying to say is that in general the case is ambiguous.

    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.
  • Xingtao zhao at Oct 9, 2014 at 10:46 pm
    I don't agree with you on this. This is a consistent behaviour. When you
    use "type xxx xxx", you always define a new type, there are no methods
    attached to this type (unless it is a struct with embedded type). We
    already allow to define new type on existing type and clear out all of old
    methods. I don't think to allow define methods on named pointer type (in
    fact, a completely new type) could introduce more ambiguous than defining
    methods on new named types of an existing non-pointer 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.
  • Ian Lance Taylor at Oct 9, 2014 at 11:06 pm

    On Thu, Oct 9, 2014 at 3:46 PM, xingtao zhao wrote:

    I don't agree with you on this. This is a consistent behaviour. When you use
    "type xxx xxx", you always define a new type, there are no methods attached
    to this type (unless it is a struct with embedded type). We already allow to
    define new type on existing type and clear out all of old methods. I don't
    think to allow define methods on named pointer type (in fact, a completely
    new type) could introduce more ambiguous than defining methods on new named
    types of an existing non-pointer type.
    That's not my point.

    Here is an example of my point.


    type T int

    func (t *T) Get() T {
         return *t + 1
    }

    type P *T

    func (p P) Get() T {
         return *p + 2
    }

    func F() {
         var v1 T
         var v2 = &v1
         var v3 P = &v1
         fmt.Println(v1.Get(), v2.Get(), v3.Get())
    }


    What do the various Get methods return? Yes, we can define an answer.
    But this invites confusion. Why invite confusion when there are other
    perfectly good ways to do the same thing?

    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.
  • Xingtao zhao at Oct 9, 2014 at 11:49 pm
    Yes, I totally understand this. My point is that there are no differences
    between your example and the one using new named non-pointer type:

    type T int

    func (t T) Get() T {
         return t + 1
    }

    type P T

    func (p P) Get() T {
         return p + 2
    }

    func F() {
         var v1 T
         var v2 = v1
         *var v3 = P(v1)*
         fmt.Println(v1.Get(), v2.Get(), v3.Get())
    }

    I agree that this is a little bit more explicitly, because you can not
    rewrite the bold line into "var v3 P = v1" as in your example, while in
    your example you could also write as "var v3 = P(&v1)".
    On Thu, Oct 9, 2014 at 4:06 PM, Ian Lance Taylor wrote:
    On Thu, Oct 9, 2014 at 3:46 PM, xingtao zhao wrote:

    I don't agree with you on this. This is a consistent behaviour. When you use
    "type xxx xxx", you always define a new type, there are no methods attached
    to this type (unless it is a struct with embedded type). We already allow to
    define new type on existing type and clear out all of old methods. I don't
    think to allow define methods on named pointer type (in fact, a
    completely
    new type) could introduce more ambiguous than defining methods on new named
    types of an existing non-pointer type.
    That's not my point.

    Here is an example of my point.


    type T int

    func (t *T) Get() T {
    return *t + 1
    }

    type P *T

    func (p P) Get() T {
    return *p + 2
    }

    func F() {
    var v1 T
    var v2 = &v1
    var v3 P = &v1
    fmt.Println(v1.Get(), v2.Get(), v3.Get())
    }


    What do the various Get methods return? Yes, we can define an answer.
    But this invites confusion. Why invite confusion when there are other
    perfectly good ways to do the same thing?

    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.
  • Ian Lance Taylor at Oct 10, 2014 at 12:47 am

    On Thu, Oct 9, 2014 at 4:49 PM, xingtao zhao wrote:
    Yes, I totally understand this. My point is that there are no differences
    between your example and the one using new named non-pointer type:
    I don't agree.
    I agree that this is a little bit more explicitly, because you can not
    rewrite the bold line into "var v3 P = v1" as in your example, while in your
    example you could also write as "var v3 = P(&v1)".
    But that's an example of my point. If we permit methods on named
    pointer types, then the methods change based on an implicit type
    conversion. There is no case where that happens in Go at present. In
    my program the implicit type conversion is fairly obvious, but if we
    change v3 to be a global variable or a function parameter then the
    type is far from the value.

    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.
  • Xingtao zhao at Oct 10, 2014 at 1:09 am
    I agree. An implicit type conversion is happened in your example. That's
    bad. Your explanation makes sense. Thanks!
    On Thu, Oct 9, 2014 at 5:47 PM, Ian Lance Taylor wrote:
    On Thu, Oct 9, 2014 at 4:49 PM, xingtao zhao wrote:

    Yes, I totally understand this. My point is that there are no differences
    between your example and the one using new named non-pointer type:
    I don't agree.
    I agree that this is a little bit more explicitly, because you can not
    rewrite the bold line into "var v3 P = v1" as in your example, while in your
    example you could also write as "var v3 = P(&v1)".
    But that's an example of my point. If we permit methods on named
    pointer types, then the methods change based on an implicit type
    conversion. There is no case where that happens in Go at present. In
    my program the implicit type conversion is fairly obvious, but if we
    change v3 to be a global variable or a function parameter then the
    type is far from the value.

    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.
  • Milo Christiansen at Oct 9, 2014 at 9:22 pm
    I dislike this little limitation, it would not be that hard to allow
    methods on such a type would it?

    For one thing it would remove the need for extra parentheses when doing
    conversions.
    eg: (*SomeType)(value)
    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile (
    http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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.
  • Xingtao zhao at Oct 9, 2014 at 9:52 pm
    Yes, this is another usecase :)
    On Thursday, October 9, 2014 2:22:08 PM UTC-7, milo.chr...@gmail.com wrote:

    I dislike this little limitation, it would not be that hard to allow
    methods on such a type would it?

    For one thing it would remove the need for extra parentheses when doing
    conversions.
    eg: (*SomeType)(value)
    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile (
    http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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.
  • Milo Christiansen at Oct 9, 2014 at 9:56 pm
    There is one very obvious use for slice pointers, when you want to be able
    to use append on one copy and have the other copies show the changes.
    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile (
    http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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 Oct 9, 2014 at 10:11 pm

    On Thu, Oct 9, 2014 at 2:55 PM, wrote:
    There is one very obvious use for slice pointers, when you want to be able
    to use append on one copy and have the other copies show the changes.
    That is true, but, to be clear, that is not an argument for supporting
    methods on named pointer types. You can name the slice type and
    define pointer methods on that.

    Ian


    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile
    (http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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.
  • Xingtao zhao at Oct 9, 2014 at 10:15 pm
    Yes, I want a mutable stack in the function. The stack is just an example
    to show the usecase.

    On Thursday, October 9, 2014 2:55:58 PM UTC-7, milo.chr...@gmail.com wrote:

    There is one very obvious use for slice pointers, when you want to be able
    to use append on one copy and have the other copies show the changes.
    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile (
    http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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.
  • DV at Oct 9, 2014 at 10:32 pm
    Something like this?
    http://play.golang.org/p/Hp8h0-fl_F

    On Thursday, October 9, 2014 4:15:19 PM UTC-6, xingtao zhao wrote:

    Yes, I want a mutable stack in the function. The stack is just an example
    to show the usecase.


    On Thursday, October 9, 2014 2:55:58 PM UTC-7, milo.chr...@gmail.com
    wrote:
    There is one very obvious use for slice pointers, when you want to be
    able to use append on one copy and have the other copies show the changes.
    On Thursday, October 9, 2014 5:06:42 PM UTC-4, xingtao zhao wrote:

    I am trying to do the following but it des not compile (
    http://play.golang.org/p/HTWEQ98MPZ):

    package main

    import "fmt"

    type Stack *[]int
    func (s Stack) Push(e int) { *s = append(*s, e) }
    func (s Stack) Top() int { return (*s)[len(*s)-1] }
    func (s Stack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &[]int{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Nor does this work (http://play.golang.org/p/11hX3oRnIU):

    package main

    import "fmt"

    type ConcretStack []int
    type Stack *ConcretStack
    func (s *ConcretStack) Push(e int) { *s = append(*s, e) }
    func (s *ConcretStack) Top() int { return (*s)[len(*s)-1] }
    func (s *ConcretStack) Pop() { *s = (*s)[:len(*s)-1] }

    func main() {
    var s Stack = &ConcretStack{}
    s.Push(1)
    s.Push(2)
    s.Push(3)
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    fmt.Println(s.Pop())
    }

    Does any one have some ideas on this?
    --
    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
postedOct 9, '14 at 9:06p
activeOct 10, '14 at 1:09a
posts17
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase