$externalize fixes #391
$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.
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.
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.
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