You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The $internalize creates a new array that is written to, but that new array is never set back to b.Object.V meaning b.V is not updated.
This isn't a problem with slices because the value is assigned to the externalized value instead. The following is the same example code above expect with [3] changed to [] in both locations then translated into JS:
The compiler code, at statements.go:737, generating this code could do one of the following:
Pass in a flag to translateExpr to indicate that the result is the left hand side of an assignment. In this case the expression must reference the actual data being assigned or create a proxy to perform the conversion when a value is set (if such a thing is possible in JS). If the flag simply prevents internalization, then the copy method would have to be updated to also handle assigning to an externalized array.
The returned *expression needs to indicate the result is internalized. This is similar to how the expression can have "paren" or not and has StringWithParens() string. The idea would be that it indicates that the normal String() would internalize the value and we'd add a StringWithoutInternalize() that either returns the expression without the internalization or the same thing as String() if there is no internalization. This would allow us to use the internalize flag on *expression to know we need to create a variable for the internalized instance, then we perform the array copy, then we add the code to assign the "un-internalized" value to the externalization of the newly updated internalized instance.
These two ideas aren't the only solution, they were just the two that came to my head first. We should look into what causes the slice not to use the copy in the assignment and try to get a whole picture of how externalized arrays work before coming up with a fix.
The text was updated successfully, but these errors were encountered:
That $clone is directly above the statement.go code which does the $copy. For some reason this doesn't function either but it seems like it should be externalizing the initial value set to V. Whatever is happening, when internalizing b.V for the print it outputs [0 0 0] instead of the expected [4 5 6].
I haven't dug into this problem too far so this may be unrelated or require changes somewhere else in code. If that's the case, please move this part to it's own issue to track this as a separate issue.
Problem
In the following code, the assignment of
b.V
doesn't work:This is because the code translates into:
The
$internalize
creates a new array that is written to, but that new array is never set back tob.Object.V
meaningb.V
is not updated.This isn't a problem with slices because the value is assigned to the externalized value instead. The following is the same example code above expect with
[3]
changed to[]
in both locations then translated into JS:Possible Fixes
The compiler code, at statements.go:737, generating this code could do one of the following:
Pass in a flag to
translateExpr
to indicate that the result is the left hand side of an assignment. In this case the expression must reference the actual data being assigned or create a proxy to perform the conversion when a value is set (if such a thing is possible in JS). If the flag simply prevents internalization, then the copy method would have to be updated to also handle assigning to an externalized array.The returned
*expression
needs to indicate the result is internalized. This is similar to how the expression can have "paren" or not and hasStringWithParens() string
. The idea would be that it indicates that the normalString()
would internalize the value and we'd add aStringWithoutInternalize()
that either returns the expression without the internalization or the same thing asString()
if there is no internalization. This would allow us to use the internalize flag on*expression
to know we need to create a variable for the internalized instance, then we perform the array copy, then we add the code to assign the "un-internalized" value to the externalization of the newly updated internalized instance.These two ideas aren't the only solution, they were just the two that came to my head first. We should look into what causes the slice not to use the copy in the assignment and try to get a whole picture of how externalized arrays work before coming up with a fix.
The text was updated successfully, but these errors were encountered: