Add wrapper for typeof operator
#2
Conversation
|
This is now ready to my personal satisfaction. I'd love to hear feedback from someone else, if only to say "do what you want with this repo." :) |
As I continue to have no plans to use JS builtin funcs, unfortunately that is the only thing I can say here: I don't have any specific comments. (This doesn't mean there's no one else who would find this useful, and a small chance I will find this useful in the future.) |
README.md
Outdated
There was a problem hiding this comment.
I suggest avoiding relying on gopherjs get. See gopherjs/gopherjs#270.
Instead, you can opt to go for:
go get -u -d -tags=js github.com/gopherjs/jsbuiltin
|
In the absence of (to my knowledge, anyway) any official developer guidelines, I prefer to exercise caution with my commit access, even though I'm the only one who's done any work on this repo. It no longer bears only my name, so I feel caution is the responsible course. On the other hand, I also don't want to burden you, @shurcooL, or anyone else. I'll go ahead and merge this, as it is something I will use immediately, and can always be tweaked later if other feedback comes in at a later date. |
Add wrapper for `typeof` operator
|
That's a good way to approach it @flimzy, thanks. |
|
Also, you're welcome to use branches for feature development in this repo, if you don't want to have to work on a fork. |
2 participants
This is a work in progress, and not yet ready to merge.I'm curious whether this is a good idea. I remember reading somewhere (I can't find it now) that Richard suggested "manual" reflection on
js.Objects to determine their type (i.e. checking for the existence of object methods as evidence for the object's type). The approach in this PR seems far easier to me when dealing with primitive types, and I suspect more efficient in many cases.My questions:
typeofto Go? Perhaps this has been discussed somewhere I haven't seen.typeofoperator in a function which isevaled). The eval runs only once, so the normal efficiency concerns of 'eval' shouldn't matter too much here. But perhaps there are other drawbacks I haven't considered.For background, the reason I care about this is that I have a jQuery Mobile event handler which passes either a DOM object or a URL string as one argument to a particular callback. At the moment, I'm determining the object type by comparing its
.String()output to[object Object], which works in my case (since a URL ought never equal that string), but direct access totypeofseems more fool-proof, and much simpler than writing complex heuristics in my code.If it is determined that this approach is basically sound, I still need to add additional error checking before merging. It's presently easy to crash the Typeof() function by passing certain JS-unfriendly data structures (e.g.
map[string]string{}or evenjs.Object{})