Hi.
I found interesting case where tempVectors can be used in remote scenarios. The store into remote temp can be really remote (not just about outer context).
I played with following example:
| temp |
temp := 10.
remote evaluate: [temp := temp + 1].
temp.
For the moment forget about remote thing and look into it as a normal local case:
temp var here is managed indirectly through tempVector. You can see it using expression after first assignment:
thisContext at: 1 "=>#(10)"
So the value in fact is stored in the array instance and read from it.
But because of optimization it happens out of the array control. No #at: and #at:put: messages are sent during this code. VM magically changes the state of this array (there are special bytecodes for this).
Now my remote use case. Imagine that vm actually sends #at: and #at:put: messages to tempVector. Then remoting engine can transfer temp vector (as part of context) as a proxy. So on remote side the block [temp := temp + 1] will actually ask the sender (client) for the value and for the storage. So all block semantics will be supported. Temp in remote outer context will be modified. I think it would be super cool if such transparency would be possible.
I played with this example using Seamless in Pharo. It already works in the way I described but due to VM optimization it does not provide expected behavior. And worse than that it actually corrupts transferred proxy because in place of array the proxy instance is materialized.
This leads us to the issue with safety of tempVector operations. Following example shows how we can affect the state of tempVector using reflection:
It is cool that we can do it. But there is no any safety check in the VM level over tempVector object: