FAQ
I am wondering about why have methods & receivers while we have function
that take parameters? Is it convenience in case of interface or in general.

Like for this example: http://play.golang.org/p/Xyj8Z7Isv4

We can just live with GetValue2() method and compiler accepts t.GetValue2()
injecting t wherever it finds in function parameter at compile time and
also make decision about pass by reference or value.


type Type1 string

func (t *Type1) GetValue() string{
return fmt.Sprint("Value is ",*t)
}

func GetValue2(t *Type1) string{
return fmt.Sprint("Value is ",*t)
}


func main() {
var t Type1 = "type1val"
fmt.Println(t.GetValue()) // if we have GetValue2 only then we can make it
compile like: t.GetValue2()
fmt.Println(GetValue2(&t))
}


--
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/groups/opt_out.

Search Discussions

  • Jesse McNelis at Jan 8, 2014 at 6:42 am

    On Wed, Jan 8, 2014 at 5:29 PM, Abhijit Kadam wrote:

    I am wondering about why have methods & receivers while we have function
    that take parameters? Is it convenience in case of interface or in general.

    Like for this example: http://play.golang.org/p/Xyj8Z7Isv4

    We can just live with GetValue2() method and compiler accepts
    t.GetValue2() injecting t wherever it finds in function parameter at
    compile time and also make decision about pass by reference or value.
    Functions and methods have different meaning and we can take advantage of
    that.
    Methods attach functions to types and thus allow the types to implement
    interfaces.
    Methods are also accessible through reflection at runtime.
    Methods are namespaced according to their type, allowing many methods of
    the same name to be defined in a package.
    Functions that aren't explicitly referenced can be removed at compile time
    without breaking runtime reflection allowing us to reduce the size of the
    binaries produced.



    --
    =====================
    http://jessta.id.au

    --
    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/groups/opt_out.
  • Chris dollin at Jan 8, 2014 at 9:09 am

    On 8 January 2014 06:29, Abhijit Kadam wrote:

    I am wondering about why have methods & receivers while we have function
    that take parameters? Is it convenience in case of interface or in general.
    It's for interfaces.

    (It's not "convenience in case if interface"; it's what interfaces are
    fundamentally /for/ in Go. If you're not using interfaces then methods
    just give you nice function-call syntax and namespaced function-like
    things, the latter being really handy, but methods are how types
    satisfy interfaces.)

    Chris

    --
    Chris "allusive" Dollin

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 8, '14 at 6:29a
activeJan 8, '14 at 9:09a
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase