Get variables names

[Dumitru Ungureanu]

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"

[Jan Mercl]

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

[stevewang]

You can get a variable's type, but not its name.

Go is not so dynamic as you expected.

[Dumitru Ungureanu]

I imagine compiling the source would change a few things, variables names being one.

[bryanturley]

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

[stevewang]

If you insist on doing that thing, it can be done by programming on your own like this:

http://play.golang.org/p/6fat821Bmd

[stevewang]

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?

[John Beshir]

On Sat, Oct 13, 2012 at 6:25 PM, Dumitru Ungureanu <itmi...@gmail.com> 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.

[Dumitru Ungureanu]

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]

On Sat, Oct 13, 2012 at 10:03 PM, Dumitru Ungureanu <itmi...@gmail.com> 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]

Interesting. Thanks for the example. It's not practical but interesting nontheless.

[Dumitru Ungureanu]

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]

I mean, with/when running a Go binary, something internal to the executable file, not with its creation.

[Jan Mercl]

On Sat, Oct 13, 2012 at 10:25 PM, Dumitru Ungureanu <itmi...@gmail.com> 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]

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 own like this:

http://play.golang.org/p/6fat821Bmd

 
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]

Thanks for clarifications.

[ro...@kabiev.com]

// p.Query is "select * from o_settings('get_by_id', '{"id":8,"changes":null,"search_criteria":null}');"


logme(p.Query())
// you see in console:
//LOGME: p.Query() = "select * from o_settings('get_by_id', '{"id":8,"changes":null,"search_criteria":null}');"
//


func logme(nup string) {
 //for debugging
 _, file, no, ok := runtime.Caller(1)

 if !ok {
      log.Println(nup)
 }

 f, err := os.Open(file)
 try(err)
 defer f.Close()

 scanner := bufio.NewScanner(f)
 try(err)
 try(scanner.Err())

 re := regexp.MustCompile(`logme\((.+)\)`)

 var rowNum int
 for scanner.Scan() {
   rowNum ++
   if rowNum == no {
     nupName := re.FindStringSubmatch(scanner.Text())[1] //берем второе попадание
     log.Printf(`LOGME: %s = "%s" %s`, nupName, nup, "\n")
   }
  }
}

суббота, 13 октября 2012 г., 20:12:42 UTC+3 пользователь Dumitru Ungureanu написал: