-
Notifications
You must be signed in to change notification settings - Fork 7
Add wrapper for typeof
operator
#2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.) |
@@ -53,7 +54,7 @@ and its current state in this package. | |||
Get or update this package and dependencies with: | |||
|
|||
``` | |||
go get -u github.com/gopherjs/jsbuiltin | |||
gopherjs get github.com/gopherjs/jsbuiltin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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.Object
s 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:
typeof
to Go? Perhaps this has been discussed somewhere I haven't seen.typeof
operator in a function which iseval
ed). 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 totypeof
seems 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{}
)