FAQ
Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

Also.. I've checked the spec but can't find it.. Are type switches made at
runtime or compile time?

Thanks,
Carlos

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

  • Jan Mercl at Apr 6, 2013 at 9:52 pm

    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • Carlos Cobo at Apr 6, 2013 at 10:28 pm
    I thought type name would answer everything, it seems not. I'll explain
    myself.

    I was toying around and thought how I would do to implement *something
    similar* to an algebraic data type in go.
    So IntBool should be "equivalent" to something that can only hold an int or
    a bool, preferably type safe.

    My play paste was the solution I came with to do this.

    I always try to minimize, or avoid, anything "whatever interface{}"
    related; there's also the reflect package, of course, but it involves a
    hell of stuff (including unsafe) so.. no thanks.

    Regarding my question about type switches.. You just answered me, it has to
    be done at runtime, yes or yes.

    Thanks Jan.
    On Saturday, April 6, 2013 11:52:28 PM UTC+2, Jan Mercl wrote:
    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • Skybrian at Apr 6, 2013 at 11:06 pm
    For such a simple type, I think it might help to think about how you'd lay
    out the data in a network protocol? I'd use a tag to avoid the pointers:
    http://play.golang.org/p/_Bz_1eVOEb

    An alternate style (used in go/ast) is to use an interface, but with a
    non-exported function to prevent any implementations outside the package.
    Here's a simple expression grammar:
    http://play.golang.org/p/hqjRPgG0Ll
    On Saturday, April 6, 2013 3:28:43 PM UTC-7, Carlos Cobo wrote:

    I thought type name would answer everything, it seems not. I'll explain
    myself.

    I was toying around and thought how I would do to implement *something
    similar* to an algebraic data type in go.
    So IntBool should be "equivalent" to something that can only hold an int
    or a bool, preferably type safe.

    My play paste was the solution I came with to do this.

    I always try to minimize, or avoid, anything "whatever interface{}"
    related; there's also the reflect package, of course, but it involves a
    hell of stuff (including unsafe) so.. no thanks.

    Regarding my question about type switches.. You just answered me, it has
    to be done at runtime, yes or yes.

    Thanks Jan.
    On Saturday, April 6, 2013 11:52:28 PM UTC+2, Jan Mercl wrote:
    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • Carlos Cobo at Apr 7, 2013 at 12:24 am
    Thank you very much sir.

    I actually might end using this for a network protocol with lots of tagging
    involved.
    On Sunday, April 7, 2013 1:06:44 AM UTC+2, skyb...@google.com wrote:

    For such a simple type, I think it might help to think about how you'd lay
    out the data in a network protocol? I'd use a tag to avoid the pointers:
    http://play.golang.org/p/_Bz_1eVOEb

    An alternate style (used in go/ast) is to use an interface, but with a
    non-exported function to prevent any implementations outside the package.
    Here's a simple expression grammar:
    http://play.golang.org/p/hqjRPgG0Ll
    On Saturday, April 6, 2013 3:28:43 PM UTC-7, Carlos Cobo wrote:

    I thought type name would answer everything, it seems not. I'll explain
    myself.

    I was toying around and thought how I would do to implement *something
    similar* to an algebraic data type in go.
    So IntBool should be "equivalent" to something that can only hold an int
    or a bool, preferably type safe.

    My play paste was the solution I came with to do this.

    I always try to minimize, or avoid, anything "whatever interface{}"
    related; there's also the reflect package, of course, but it involves a
    hell of stuff (including unsafe) so.. no thanks.

    Regarding my question about type switches.. You just answered me, it has
    to be done at runtime, yes or yes.

    Thanks Jan.
    On Saturday, April 6, 2013 11:52:28 PM UTC+2, Jan Mercl wrote:
    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • Gordon Klaus at Apr 7, 2013 at 12:49 am

    On Saturday, April 6, 2013 7:06:44 PM UTC-4, skyb...@google.com wrote:

    For such a simple type, I think it might help to think about how you'd lay
    out the data in a network protocol? I'd use a tag to avoid the pointers:
    http://play.golang.org/p/_Bz_1eVOEb
    Why not just cram it in an interface{}. It's more general than necessary,
    but that's what the encapsulating struct is there to manage.
    An alternate style (used in go/ast) is to use an interface, but with a
    non-exported function to prevent any implementations outside the package.
    I, too, used to think that a non-exported interface method would prevent
    outside implementations. Not so, thanks to interface embedding:
    http://play.golang.org/p/DMSc9rDFxt Not as long as the unexported method
    doesn't do anything useful...

    Here's a simple expression grammar:
    http://play.golang.org/p/hqjRPgG0Ll
    On Saturday, April 6, 2013 3:28:43 PM UTC-7, Carlos Cobo wrote:

    I thought type name would answer everything, it seems not. I'll explain
    myself.

    I was toying around and thought how I would do to implement *something
    similar* to an algebraic data type in go.
    So IntBool should be "equivalent" to something that can only hold an int
    or a bool, preferably type safe.

    My play paste was the solution I came with to do this.

    I always try to minimize, or avoid, anything "whatever interface{}"
    related; there's also the reflect package, of course, but it involves a
    hell of stuff (including unsafe) so.. no thanks.

    Regarding my question about type switches.. You just answered me, it has
    to be done at runtime, yes or yes.

    Thanks Jan.
    On Saturday, April 6, 2013 11:52:28 PM UTC+2, Jan Mercl wrote:
    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • Skybrian at Apr 7, 2013 at 1:11 am

    On Saturday, April 6, 2013 5:49:43 PM UTC-7, gordon...@gmail.com wrote:
    On Saturday, April 6, 2013 7:06:44 PM UTC-4, skyb...@google.com wrote:

    For such a simple type, I think it might help to think about how you'd
    lay out the data in a network protocol? I'd use a tag to avoid the
    pointers:
    http://play.golang.org/p/_Bz_1eVOEb
    Why not just cram it in an interface{}. It's more general than necessary,
    but that's what the encapsulating struct is there to manage.
    Sure, I think it's the same size; an interface{} is the size of two ints
    and the bits are padded out to take up an int. If it were a union between a
    boolean and a byte then the interface would be larger.

    An alternate style (used in go/ast) is to use an interface, but with a
    non-exported function to prevent any implementations outside the package.
    I, too, used to think that a non-exported interface method would prevent
    outside implementations. Not so, thanks to interface embedding:
    http://play.golang.org/p/DMSc9rDFxt Not as long as the unexported method
    doesn't do anything useful...
    Wow, interesting. I hadn't realized that embedding was so close to
    subclassing. So I guess the main effect of a non-exported method is that
    you can't implement Expr accidentally.

    - Brian

    --
    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.
  • David DENG at Apr 7, 2013 at 3:53 am
    how about this?

    http://play.golang.org/p/jh-epnzexY

    If you have to do type checking more often and more efficiently, add an int-typed
    field to represent it. like this:

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

    David
    On Sunday, April 7, 2013 6:28:43 AM UTC+8, Carlos Cobo wrote:

    I thought type name would answer everything, it seems not. I'll explain
    myself.

    I was toying around and thought how I would do to implement *something
    similar* to an algebraic data type in go.
    So IntBool should be "equivalent" to something that can only hold an int
    or a bool, preferably type safe.

    My play paste was the solution I came with to do this.

    I always try to minimize, or avoid, anything "whatever interface{}"
    related; there's also the reflect package, of course, but it involves a
    hell of stuff (including unsafe) so.. no thanks.

    Regarding my question about type switches.. You just answered me, it has
    to be done at runtime, yes or yes.

    Thanks Jan.
    On Saturday, April 6, 2013 11:52:28 PM UTC+2, Jan Mercl wrote:
    On Sat, Apr 6, 2013 at 11:44 PM, Carlos Cobo wrote:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI
    Depends on what you are trying to solve. You shown only the solution,
    not the problem.
    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?
    What a type switches at compile time should do?

    -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/groups/opt_out.
  • peterGo at Apr 7, 2013 at 12:25 pm
    Carlos,

    It's ineffectual.

    For example, at work, there are multiple ways to identify you: employee
    number, name, email address.

    package main

    import "fmt"

    type Num int
    type Name string
    type Email string

    type Id struct {
    num Num
    name Name
    email Email
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    return &Id{num: id}
    case Name:
    return &Id{name: id}
    case Email:
    return &Id{email: id}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch {
    case id.num != 0:
    return fmt.Sprintf("Id.Num: %v", id.num)
    case id.name != "":
    return fmt.Sprintf("Id.Name: %v", id.name)
    case id.email != "":
    return fmt.Sprintf("Id.Email: %v", id.email)
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos

    Peter
    On Saturday, April 6, 2013 5:44:21 PM UTC-4, Carlos Cobo wrote:

    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?

    Thanks,
    Carlos
    --
    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.
  • Carlos Cobo at Apr 7, 2013 at 1:38 pm
    This is fine, type safe yay!

    But allocates too much memory (1 int + 2 strings per Id).

    El domingo, 7 de abril de 2013 14:25:34 UTC+2, peterGo escribió:
    Carlos,

    It's ineffectual.

    For example, at work, there are multiple ways to identify you: employee
    number, name, email address.

    package main

    import "fmt"

    type Num int
    type Name string
    type Email string

    type Id struct {
    num Num
    name Name
    email Email
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    return &Id{num: id}
    case Name:
    return &Id{name: id}
    case Email:
    return &Id{email: id}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch {
    case id.num != 0:
    return fmt.Sprintf("Id.Num: %v", id.num)
    case id.name != "":
    return fmt.Sprintf("Id.Name: %v", id.name)
    case id.email != "":
    return fmt.Sprintf("Id.Email: %v", id.email)
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos

    Peter
    On Saturday, April 6, 2013 5:44:21 PM UTC-4, Carlos Cobo wrote:

    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made
    at runtime or compile time?

    Thanks,
    Carlos
    --
    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.
  • peterGo at Apr 7, 2013 at 3:50 pm
    Carlos,

    The example assumed that you had all three types of Id. If you only have
    one of the three possible types of Id:

    package main

    import (
    "encoding/binary"
    "fmt"
    )

    type Num int32
    type Name string
    type Email string

    const (
    tagNum = iota
    tagName
    tagEmail
    )

    type Id struct {
    tag int8
    data []byte
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    var buf [10]byte
    n := binary.PutVarint(buf[:], int64(id))
    data := make([]byte, n)
    copy(data, buf[:])
    return &Id{tag: tagNum, data: data}
    case Name:
    return &Id{tag: tagName, data: []byte(id)}
    case Email:
    return &Id{tag: tagEmail, data: []byte(id)}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch id.tag {
    case tagNum:
    num, _ := binary.Varint(id.data)
    return fmt.Sprintf("Id.Num: %v", int32(num))
    case tagName:
    return fmt.Sprintf("Id.Name: %v", string(id.data))
    case tagEmail:
    return fmt.Sprintf("Id.Email: %v", string(id.data))
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    fmt.Println(NewId(Name("carlos@example.com")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos
    Id.Name: carlos@example.com

    Peter
    On Sunday, April 7, 2013 9:38:17 AM UTC-4, Carlos Cobo wrote:

    This is fine, type safe yay!

    But allocates too much memory (1 int + 2 strings per Id).

    El domingo, 7 de abril de 2013 14:25:34 UTC+2, peterGo escribió:
    Carlos,

    It's ineffectual.

    For example, at work, there are multiple ways to identify you: employee
    number, name, email address.

    package main

    import "fmt"

    type Num int
    type Name string
    type Email string

    type Id struct {
    num Num
    name Name
    email Email
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    return &Id{num: id}
    case Name:
    return &Id{name: id}
    case Email:
    return &Id{email: id}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch {
    case id.num != 0:
    return fmt.Sprintf("Id.Num: %v", id.num)
    case id.name != "":
    return fmt.Sprintf("Id.Name: %v", id.name)
    case id.email != "":
    return fmt.Sprintf("Id.Email: %v", id.email)
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos

    Peter
    On Saturday, April 6, 2013 5:44:21 PM UTC-4, Carlos Cobo wrote:

    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made
    at runtime or compile time?

    Thanks,
    Carlos
    --
    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.
  • Carlos Cobo at Apr 7, 2013 at 4:03 pm
    Of course! So simple.. I never thought of tag + []byte... Thanks Peter.

    El domingo, 7 de abril de 2013 17:50:43 UTC+2, peterGo escribió:
    Carlos,

    The example assumed that you had all three types of Id. If you only have
    one of the three possible types of Id:

    package main

    import (
    "encoding/binary"
    "fmt"
    )

    type Num int32
    type Name string
    type Email string

    const (
    tagNum = iota
    tagName
    tagEmail
    )

    type Id struct {
    tag int8
    data []byte
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    var buf [10]byte
    n := binary.PutVarint(buf[:], int64(id))
    data := make([]byte, n)
    copy(data, buf[:])
    return &Id{tag: tagNum, data: data}
    case Name:
    return &Id{tag: tagName, data: []byte(id)}
    case Email:
    return &Id{tag: tagEmail, data: []byte(id)}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch id.tag {
    case tagNum:
    num, _ := binary.Varint(id.data)
    return fmt.Sprintf("Id.Num: %v", int32(num))
    case tagName:
    return fmt.Sprintf("Id.Name: %v", string(id.data))
    case tagEmail:
    return fmt.Sprintf("Id.Email: %v", string(id.data))
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    fmt.Println(NewId(Name("carlos@example.com <javascript:>")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos
    Id.Name: car...@example.com <javascript:>

    Peter
    On Sunday, April 7, 2013 9:38:17 AM UTC-4, Carlos Cobo wrote:

    This is fine, type safe yay!

    But allocates too much memory (1 int + 2 strings per Id).

    El domingo, 7 de abril de 2013 14:25:34 UTC+2, peterGo escribió:
    Carlos,

    It's ineffectual.

    For example, at work, there are multiple ways to identify you: employee
    number, name, email address.

    package main

    import "fmt"

    type Num int
    type Name string
    type Email string

    type Id struct {
    num Num
    name Name
    email Email
    }

    func NewId(v interface{}) *Id {
    switch id := v.(type) {
    case Num:
    return &Id{num: id}
    case Name:
    return &Id{name: id}
    case Email:
    return &Id{email: id}
    default:
    return nil
    }
    }

    func (id Id) String() string {
    switch {
    case id.num != 0:
    return fmt.Sprintf("Id.Num: %v", id.num)
    case id.name != "":
    return fmt.Sprintf("Id.Name: %v", id.name)
    case id.email != "":
    return fmt.Sprintf("Id.Email: %v", id.email)
    default:
    return "Id.Nil"
    }
    }

    func main() {
    fmt.Println(NewId(42))
    fmt.Println(NewId(Num(42)))
    fmt.Println(NewId(Name("Carlos")))
    }

    Output:

    <nil>
    Id.Num: 42
    Id.Name: Carlos

    Peter
    On Saturday, April 6, 2013 5:44:21 PM UTC-4, Carlos Cobo wrote:

    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made
    at runtime or compile time?

    Thanks,
    Carlos
    --
    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.
  • Carlos Cobo at Apr 7, 2013 at 1:36 pm
    Ok, IntBool was simple. Let's make this a bit harder...

    Have a look at this: http://wiki.vg/Entities#Entity_Metadata_Format

    Instead of *int* and *bool*, now there are 6 different types.

    *Approach 1: Interface*

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

    But that way I should make 6 different methods, one for each type, to
    satisfy the Entry interface.

    *Approach 2: Tagging*

    http://play.golang.org/p/2vTdX-POVX

    But still isn't typesafe and there is casting involved.

    -----

    Approach 1 allocates TOO much memory.
    Approach 2 isn't type safe.

    Is there another approach?

    El sábado, 6 de abril de 2013 23:44:21 UTC+2, Carlos Cobo escribió:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made at
    runtime or compile time?

    Thanks,
    Carlos
    --
    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.
  • Martin Schnabel at Apr 7, 2013 at 4:11 pm

    On 04/07/2013 03:35 PM, Carlos Cobo wrote:
    Ok, IntBool was simple. Let's make this a bit harder...

    Have a look at this: http://wiki.vg/Entities#Entity_Metadata_Format

    Instead of *int* and *bool*, now there are 6 different types.

    *Approach 1: Interface*

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

    But that way I should make 6 different methods, one for each type, to
    satisfy the Entry interface.

    *Approach 2: Tagging*

    http://play.golang.org/p/2vTdX-POVX

    But still isn't typesafe and there is casting involved.

    -----

    Approach 1 allocates TOO much memory.
    Approach 2 isn't type safe.

    Is there another approach?
    the code looks way too complicated.
    just use an empty interface and type assert or type switch when you
    actually need to. http://play.golang.org/p/5ruzEDsWTA

    --
    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.
  • Gerard at Apr 7, 2013 at 4:19 pm
    Yes, this is interesting, isn't it? The easiest way is to use interface{}
    as argument or return value. But that is ugly IMO.

    Now, let's take a look at the sort package. With sort.Interface you can
    sort any type. It has 3 functions and no-one has an interface{} argument.

    I think when dealing with this kind of problems, abstract thinking is the
    answer.

    A possible solution can be using a function as argument for instance.


    Op zondag 7 april 2013 15:35:55 UTC+2 schreef Carlos Cobo het volgende:
    Ok, IntBool was simple. Let's make this a bit harder...

    Have a look at this: http://wiki.vg/Entities#Entity_Metadata_Format

    Instead of *int* and *bool*, now there are 6 different types.

    *Approach 1: Interface*

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

    But that way I should make 6 different methods, one for each type, to
    satisfy the Entry interface.

    *Approach 2: Tagging*

    http://play.golang.org/p/2vTdX-POVX

    But still isn't typesafe and there is casting involved.

    -----

    Approach 1 allocates TOO much memory.
    Approach 2 isn't type safe.

    Is there another approach?

    El sábado, 6 de abril de 2013 23:44:21 UTC+2, Carlos Cobo escribió:
    Is this considered idiomatic? http://play.golang.org/p/J2cAwJ4KiI

    Also.. I've checked the spec but can't find it.. Are type switches made
    at runtime or compile time?

    Thanks,
    Carlos
    --
    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
postedApr 6, '13 at 9:44p
activeApr 7, '13 at 4:19p
posts15
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase