FAQ
From what I read, it's not possible, but I thought I double check, just to
make sure, can we get variables names?

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

I'd expect this instead:
"variable x has value 0"

--

Search Discussions

  • Stevewang at Oct 13, 2012 at 5:21 pm
    You can get a variable's type, but not its name.
    Go is not so dynamic as you expected.
    On Sunday, October 14, 2012 1:12:43 AM UTC+8, Dumitru Ungureanu wrote:

    From what I read, it's not possible, but I thought I double check, just to
    make sure, can we get variables names?

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

    I'd expect this instead:
    "variable x has value 0"
    --
  • Stevewang at Oct 13, 2012 at 6:17 pm
    If you insist on doing that thing, it can be done by programming on your
    own like this:
    http://play.golang.org/p/6fat821Bmd
    On Sunday, October 14, 2012 1:21:15 AM UTC+8, stevewang wrote:

    You can get a variable's type, but not its name.
    Go is not so dynamic as you expected.
    On Sunday, October 14, 2012 1:12:43 AM UTC+8, Dumitru Ungureanu wrote:

    From what I read, it's not possible, but I thought I double check, just
    to make sure, can we get variables names?

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

    I'd expect this instead:
    "variable x has value 0"
    --
  • Stevewang at Oct 13, 2012 at 6:33 pm
    But in fact, an object may have more than one name, which are just
    references to the object.
    So which one of them do you expect to get?
    On Sunday, October 14, 2012 2:17:55 AM UTC+8, stevewang wrote:

    If you insist on doing that thing, it can be done by programming on your
    own like this:
    http://play.golang.org/p/6fat821Bmd
    On Sunday, October 14, 2012 1:21:15 AM UTC+8, stevewang wrote:

    You can get a variable's type, but not its name.
    Go is not so dynamic as you expected.
    On Sunday, October 14, 2012 1:12:43 AM UTC+8, Dumitru Ungureanu wrote:

    From what I read, it's not possible, but I thought I double check, just
    to make sure, can we get variables names?

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

    I'd expect this instead:
    "variable x has value 0"
    --
  • Dumitru Ungureanu at Oct 13, 2012 at 8:33 pm

    On Saturday, October 13, 2012 9:33:45 PM UTC+3, stevewang wrote:
    But in fact, an object may have more than one name, which are just
    references to the object.

    So which one of them do you expect to get?

    On Sunday, October 14, 2012 2:17:55 AM UTC+8, stevewang wrote:

    If you insist on doing that thing, it can be done by programming on your
    Beside the interesting example, I'd expect the original name. It's true the
    references may be pointing to the same memory address, but it's a different
    mechanism altogether.

    --
  • Dumitru Ungureanu at Oct 13, 2012 at 8:15 pm
    Interesting. Thanks for the example. It's not practical but interesting
    nontheless.
    On Saturday, October 13, 2012 9:17:55 PM UTC+3, stevewang wrote:

    If you insist on doing that thing, it can be done by programming on your
    own like this:
    http://play.golang.org/p/6fat821Bmd
    On Sunday, October 14, 2012 1:21:15 AM UTC+8, stevewang wrote:

    You can get a variable's type, but not its name.
    Go is not so dynamic as you expected.
    On Sunday, October 14, 2012 1:12:43 AM UTC+8, Dumitru Ungureanu wrote:

    From what I read, it's not possible, but I thought I double check, just
    to make sure, can we get variables names?

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

    I'd expect this instead:
    "variable x has value 0"
    --
  • Dumitru Ungureanu at Oct 13, 2012 at 5:32 pm
    I imagine compiling the source would change a few things, variables names
    being one.

    --
  • Bryanturley at Oct 13, 2012 at 5:57 pm
    The secret is simple
    http://play.golang.org/p/x-QcP1vM-C
    Since you already know the variable name, seeing as you originally typed
    it, you just have to type it twice.

    ps: lol ;)

    --
  • John Beshir at Oct 13, 2012 at 6:59 pm

    On Sat, Oct 13, 2012 at 6:25 PM, Dumitru Ungureanu wrote:
    I imagine compiling the source would change a few things, variables names
    being one.
    Compiling the source allocates a memory location corresponding to each
    variable, and converts all references to the variable to reads/writes
    of that memory location. The variable is then "forgotten". Variables
    don't really exist at runtime in compiled languages like Go, only
    locations in memory storing values of particular types, and memory
    locations don't have names.

    For example, an int64 variable would have a block of 8 bytes allocated
    for it, and then each read and write of the variable would be turned
    into an access to the memory address of that 8 bytes.

    This is fairly simplified, and there are some more complex aspects.
    For example, variables which exist more than once, like local
    variables in functions, need to have a separate location each time the
    function is called. The compiler can try to keep a variable's value in
    registers and never give it a memory location, for improved
    performance, if it doesn't alter behaviour of the code. That kind of
    thing. The way all this works is implementation details, though, and
    doesn't need to be fully understood, so long as you have a grasp of
    the basic model.

    All this means that variables don't "have" names, as such, at runtime.

    --
  • Jan Mercl at Oct 13, 2012 at 5:41 pm

    On Sat, Oct 13, 2012 at 7:12 PM, Dumitru Ungureanu wrote:
    From what I read, it's not possible, but I thought I double check, just to
    make sure, can we get variables names?

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

    I'd expect this instead:
    "variable x has value 0"
    You are writing the name of the variable in the source immediately
    after the '?' Printf item, so the name of the variable is statically
    know. What's the point?

    -j

    --
  • Dumitru Ungureanu at Oct 13, 2012 at 8:03 pm
    I suspected as much, and I'm versed enough programmer to understand the
    difference between interpreted and compiled.

    I was wondering because of two things:

    - Go is not 100% compiled (?) to native code, kind of like Visual FoxPro,
    maybe, somebody correct me...

    - for functions, you can Func.Name():
    http://golang.org/pkg/runtime/#Func.Name

    --
  • Jan Mercl at Oct 13, 2012 at 8:10 pm

    On Sat, Oct 13, 2012 at 10:03 PM, Dumitru Ungureanu wrote:
    I suspected as much, and I'm versed enough programmer to understand the
    difference between interpreted and compiled.

    I was wondering because of two things:

    - Go is not 100% compiled (?) to native code, kind of like Visual FoxPro,
    maybe, somebody correct me...
    gc & gccgo: It is 100% compiled to native code.
    - for functions, you can Func.Name():
    http://golang.org/pkg/runtime/#Func.Name
    True. W/o that human readable stack traces* are not so easy to provide ;-)

    -j

    (*) Produced w/o the assistance of a debugger etc.

    --
  • Dumitru Ungureanu at Oct 13, 2012 at 8:23 pm
    On Saturday, October 13, 2012 11:10:59 PM UTC+3, Jan Mercl wrote:
    gc & gccgo: It is 100% compiled to native code.
    It makes sense. I read somewhere though, I can't remember where, that
    there's another step involved in running a Go executable... One of those
    things that hang in the back of your mind that prove to be wrong I guess.

    --
  • Dumitru Ungureanu at Oct 13, 2012 at 8:25 pm
    I mean, with/when running a Go binary, something internal to the executable
    file, not with its creation.

    --
  • Jan Mercl at Oct 13, 2012 at 8:31 pm

    On Sat, Oct 13, 2012 at 10:25 PM, Dumitru Ungureanu wrote:
    I mean, with/when running a Go binary, something internal to the executable
    file, not with its creation.
    Perhaps some old and/or mention about the run time generation of
    (native) code for closures gets mixed in the associative memory w/
    interpreted code (which it is not either).

    -j

    --
  • Dumitru Ungureanu at Oct 13, 2012 at 9:42 pm
    Thanks for clarifications.
    On Saturday, October 13, 2012 11:31:37 PM UTC+3, Jan Mercl wrote:
    On Sat, Oct 13, 2012 at 10:25 PM, Dumitru Ungureanu wrote:
    I mean, with/when running a Go binary, something internal to the
    executable
    file, not with its creation.
    Perhaps some old and/or mention about the run time generation of
    (native) code for closures gets mixed in the associative memory w/
    interpreted code (which it is not either).

    -j
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 13, '12 at 5:12p
activeOct 13, '12 at 9:42p
posts16
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase