-
Notifications
You must be signed in to change notification settings - Fork 569
$externalize fixes #391
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
$externalize fixes #391
Conversation
@@ -114,6 +114,9 @@ var $externalize = function(v, t) { | |||
return searchJsObject(v.$get(), t.elem); | |||
case $kindStruct: | |||
var f = t.fields[0]; | |||
if (f === undefined) { |
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.
Can we make that t.fields.length === 0
? That captures the intention a bit better in my regard.
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 agree that it looks better, but the defensive coder in me, that says not to trust user input, reminds me that we haven't checked that t.fields
is an array; t.fields.length
could be undefined
and that does not equal 0.
We could have it check t.fields.length > 0
, and reverse the return
statements, although I'm not a fan of coercing undefined
.
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.
but the defensive coder in me, that says not to trust user input
As far as I can tell, fields
is not user input, it's a property that is generated by the GopherJS compiler. So it should be safe to rely on it existing.
If it always exists (I haven't confirmed, but that's my understanding), then t.fields.length === 0
would be better because it captures the intention better (as Richard said) and makes it easier to read the code.
If it doesn't always exist, we should consider either making it always exist, even if it's empty for empty structs, or consider going with if t.fields === undefined
or so.
Basically, I suggest we take the least amount of precautions that are needed to fix the issue. (Which is not what you might do in other contexts.)
We can add a test to make sure the behavior doesn't regress. Having more readable code will help with future development and maintenance. What do you think @MJKWoolnough?
This is a pretty old PR with no recent activity. Let's figure out what we can do with it: either resume making progress, or extract something useful out of it (an issue or new PR) and close it, or just close it. @neelance There have been replies to your comments, can you see if that's enough to make progress? |
The overriding of embedded fields now appears to have been fixed from the other end, as of commit The |
Thanks for following up @MJKWoolnough, that makes sense to me.
So we just need to focus on fixing this part:
Edit: I've factored it out into issue #715. |
Found a couple of bugs in how $externalize converts structs to js objects.
First, when converting an anonymous field, it gives it a name of empty string. This is not ideal, and actually causes naming collisions if you have two or more anonymous fields.
The following playground link shows this off: -
http://www.gopherjs.org/playground/#/paSROP9iN_
The js console will show an object with two fields, the NotEmpty and the empty string struct, which will be C, which has overridden B.
The second occurs when you have an empty struct, searchJsObject doesn't handle the case where there are no fields to check.
This can be shown by just printing an empty struct{} to the log: -
http://www.gopherjs.org/playground/#/PfMcT_bbbz