small curiosity about *js.Object

[Roberto Zanotto]

Hi... again.

Why is it *js.Object instead of js.Object? What happens internally?

Cheers

[Richard Musiol]

Hi Roberto,

variables/fields of type *js.Object are internally represented by the JavaScript object itself. A pointer makes much sense, because in JS there is no "by-value", every JS object is kind of a pointer in Go's terms. It's hard to give more details because it becomes complicated pretty quickly. If you're interested in finding out more, I suggest compiling simple test programs and looking at the generated code to figure out what's going on. Avoid blocking functions like fmt.Println (use println instead) to generate code which is more readable.

Cheers,

Richard

--
You received this message because you are subscribed to the Google Groups "GopherJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gopherjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roberto Zanotto]

Thanks for the quick reply.

It seems a strange choice to me, I think I would have done something like maps in Go, for which you know that they are passed around as pointers, but you don't have to write the asterisk everywhere. No big deal anyway :)

I found this while experimenting, maybe a case for numbers is missing in function $copy?
http://www.gopherjs.org/playground/#/SDSmoyp--x

[Roberto Zanotto]

Now that I think more about it, it seems to me that it's a matter of deciding if you want the users to be able to dereference js objects or not. It doesn't really make sense in javascript terms, but it could be useful from a Go point of view.

On Tuesday, September 15, 2015 at 4:37:25 AM UTC+2, Roberto Zanotto wrote:

It seems a strange choice to me, I think I would have done something like maps in Go, for which you know that they are passed around as pointers, but you don't have to write the asterisk everywhere. No big deal anyway :)