On Tuesday, 16 July 2019 at 06:12:42 UTC, Walter Bright wrote:
Now I just have to deliver the goods!
I am very excited about this, together with unique these are some
very desired semantics.
I have a practical question. In spasm I have to solve the
lifetime of javascript objects that are referenced from D. The
way it works is that objects in Javascript are put in a big array
and the index - the handle if you will - is passed to D. When D
code wants to do anything with the js object, it passes the
handle to a js glue function which looks up the object in the
table and does what it needs to.
The trick is finding an efficient mechanism to free the js
objects in the js array. At first I tried reference counting -
which worked, but introduced a lot of code bloat.
Now I have settled on having the wrapper struct (JsHandle) of the
handle be non-copyable, and pass it around by either moving or
using `ref scope` with dip1000 and @safe. Then if you need to
have the handle around for longer you can always wrap it in a RC
wrapper.
This works remarkably well. It gives cheap, efficient and safe
code and still allows multiple long-lived references with RC if
that is what is wanted.
There are 2 issues I currently have.
First some code:
---
alias Handle = uint;
struct JsHandle {
nothrow:
package Handle handle;
alias handle this;
~this() {
if (handle != invalid)
spasm_removeObject(handle);
}
@disable this(this);
}
struct HTMLElement {
spasm.bindings.dom.Element _parent;
alias _parent this;
this(JsHandle h) {
_parent = .Element(h);
}
// ... functions
}
struct HTMLCanvasElement {
spasm.bindings.html.HTMLElement _parent;
alias _parent this;
this(JsHandle h) {
_parent = .HTMLElement(h);
}
// ... functions
}
---
1) Sometimes the web api's accept an Nullable/Optional, which
means I have to wrap, for instance, the HTMLElement into an
Optional type and pass that. Of course, I want to maintain the
unique reference constraint and enforce that the Optional won't
outlive the original HTMLElement. Which I can't, since they are
all non-pointers and I can't store a scope ref inside a Optional.
The solution I have now is to create a Nullable!(T*). This does
solve the unique semantics, at the expense of having an api that
accepts both Nullable!(T) and Nullable!(T*). Pretty ugly.
2) the other issue is that I sometimes want to "upcast" a
HTMLElement to a HTMLCanvasElement. I can simply do this by
moving the handle around, but I want the HTMLCanvasElement not to
outlive the HTMLElement. Again, the solution is to involve
pointers. Since all wrapper structs have the same memory layout
(only a uint), I used this hack:
---
template as(Target) {
auto as(Source)(scope return ref Source s) {
return cast(Target*)&s;
}
}
---
Anyway my question is whether the ownership and borrowing
semantics ever gets applied to non-pointers?
