[foreign] Pulling the string on Scope

[Maurizio Cimadamore]

On 20/12/2018 13:54, Jorn Vernee wrote:
> The above example does not actually throw an exception. There is a 
> solution for this problem for Callbacks; if you have a 
> Pointer<Callback<...>> then when the pointer is de-referenced the 
> callback is added to the Scope of the enclosing Pointer, and in the 
> case of struct fields this just happens to be the same scope that the 
> struct belongs to, but this seems like an unwanted side-effect. If the 
> Callback was not in the same scope as the Pointer we inadvertently add 
> it to the wrong scope. The right way to solve this seems to be to 
> track the Scope of a Struct's field when setting it, and then setting 
> it again when getting. But, we can't ask native code to do that, so 
> maybe the only solution is to say that when you get a struct's field 
> it does not belong to any scope, and the missing exception in the 
> above example is intended behavior. Adding a resource field to the 
> scope of the enclosing struct when getting seems to make sense for 
> nested structs and fused arrays only, since you can say for sure that 
> when the struct is freed so are it's contents. 

I think a sensible behavior here is to tie the scope of whatever pointer 
we get back from a struct to the struct itself. We can't do much better 
than that, but I think it's a start, and, once we have a way to transfer 
pointer ownership, the user will be able to 'expand' the lifecycle of 
the pointer if he chooses to do so.

In the past I've looked into other solutions so that the binder could 
somehow reify all the scopes of all the pointer fields, but it seemed 
overkill (think of cases where you  have Pointer<Pointer<Pointer...>>> )

Maurizio