FAQ
Ran into a problem where an interface of underlying type "string" is
silently converted to an interface of underlying type "reflect.Value". And
an eventual panic message pointed to a completely different location/cause.

Simplified Play example. <https://play.golang.org/p/8fhaf1LMRW>

Raised a number of questions

A typed interface, X in this case, is not type specific to its underlying
type? Seems so, since the problem assignment

x = mischief(x)

does not cause an immediate error even if x is explicitly created by

x := reflect.ValueOf(s).Interface()

Is there a reason not to extend the type system to verifying the type of at
least the first level of underlying type of an interface value?

The promotion of a value to an interface does not promote the underlying
type value to the interface when the value is already a reflect.Value?
That is, reflect.Value is nominally an underlying type value container.
Does an interface value with an underlying type of reflect.Value ever make
sense? If it does, seems like there should be some path for getting at the
second level underlying type

x = mischief(x)
x = reflect.ValueOf(x).InterfaceOfNextLevelUnderlyingType()

Is there an existing reflection way of doing 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

  • Roberto Zanotto at Sep 24, 2015 at 11:34 pm
    https://play.golang.org/p/LvmE1rM8CH ;)
    On Friday, September 25, 2015 at 1:28:59 AM UTC+2, Gbr wrote:

    Ran into a problem where an interface of underlying type "string" is
    silently converted to an interface of underlying type "reflect.Value". And
    an eventual panic message pointed to a completely different location/cause.

    Simplified Play example. <https://play.golang.org/p/8fhaf1LMRW>

    Raised a number of questions

    A typed interface, X in this case, is not type specific to its underlying
    type? Seems so, since the problem assignment

    x = mischief(x)

    does not cause an immediate error even if x is explicitly created by

    x := reflect.ValueOf(s).Interface()

    Is there a reason not to extend the type system to verifying the type of
    at least the first level of underlying type of an interface value?

    The promotion of a value to an interface does not promote the underlying
    type value to the interface when the value is already a reflect.Value?
    That is, reflect.Value is nominally an underlying type value container.
    Does an interface value with an underlying type of reflect.Value ever make
    sense? If it does, seems like there should be some path for getting at the
    second level underlying type

    x = mischief(x)
    x = reflect.ValueOf(x).InterfaceOfNextLevelUnderlyingType()

    Is there an existing reflection way of doing 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.
  • Gbr at Sep 25, 2015 at 12:51 am
    Much appreciated.

    But that means I don't understand the subtle difference between
    reflect.ValueOf(X) and the type assertion X.(reflection.Value).

    From value.go, reflect.ValueOf() returns a new Value initialized to point
    to the same data as the value contained by the interface. Other than not
    (apparently) creating a new Value instance, what does a type assertion do
    differently?

    The Laws of Reflection do not touch on this point. Is there another source
    or discussion on point that you can recommend?
    On Thursday, September 24, 2015 at 4:33:59 PM UTC-7, Roberto Zanotto wrote:

    https://play.golang.org/p/LvmE1rM8CH ;)
    --
    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.
  • Roberto Zanotto at Sep 25, 2015 at 3:02 am
    If you assign something to an interface variable, no matter if it's an int,
    a string, or a reflect.Value, it gets "wrapped" inside an interface value
    and you have to use interf.(Type) to get it out. That's what the "type
    assertion" is for.
    reflect.ValueOf, instead, takes whatever you have (int, string, float) and
    wraps it inside a reflect.Value. ValueOf is not meant to pull original
    values out of interfaces, it is just meant to get a variable of type Value
    that you can inspect and manipulate with the various functions in the
    reflect package.
    On Friday, September 25, 2015 at 2:51:28 AM UTC+2, Gbr wrote:

    Much appreciated.

    But that means I don't understand the subtle difference between
    reflect.ValueOf(X) and the type assertion X.(reflection.Value).

    From value.go, reflect.ValueOf() returns a new Value initialized to point
    to the same data as the value contained by the interface. Other than not
    (apparently) creating a new Value instance, what does a type assertion do
    differently?

    The Laws of Reflection do not touch on this point. Is there another
    source or discussion on point that you can recommend?
    On Thursday, September 24, 2015 at 4:33:59 PM UTC-7, Roberto Zanotto wrote:

    https://play.golang.org/p/LvmE1rM8CH ;)
    --
    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.
  • Marvin Stenger at Sep 25, 2015 at 10:12 pm
    http://blog.golang.org/laws-of-reflection
    by Rob Pike, so its good ;)

    Am Freitag, 25. September 2015 01:28:59 UTC+2 schrieb Gbr:
    Ran into a problem where an interface of underlying type "string" is
    silently converted to an interface of underlying type "reflect.Value". And
    an eventual panic message pointed to a completely different location/cause.

    Simplified Play example. <https://play.golang.org/p/8fhaf1LMRW>

    Raised a number of questions

    A typed interface, X in this case, is not type specific to its underlying
    type? Seems so, since the problem assignment

    x = mischief(x)

    does not cause an immediate error even if x is explicitly created by

    x := reflect.ValueOf(s).Interface()

    Is there a reason not to extend the type system to verifying the type of
    at least the first level of underlying type of an interface value?

    The promotion of a value to an interface does not promote the underlying
    type value to the interface when the value is already a reflect.Value?
    That is, reflect.Value is nominally an underlying type value container.
    Does an interface value with an underlying type of reflect.Value ever make
    sense? If it does, seems like there should be some path for getting at the
    second level underlying type

    x = mischief(x)
    x = reflect.ValueOf(x).InterfaceOfNextLevelUnderlyingType()

    Is there an existing reflection way of doing 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
postedSep 24, '15 at 11:29p
activeSep 25, '15 at 10:12p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase