Thanks for your reply.
I think I already tried something like
var cr1: sink cairo.Context
Run
but it does not compiled -- the reason may be that I do not yet understand sink
for local vars good enough.
But I just read your blog post about new runtime and owned refs
As far as I can understand the situation your macro should generate a proc that
uses a `sink` parameter.
> In your case, if you use ptr or template for aliasing instead of let/var you
> will not ...
Yes, but I can not see how this really helps.
gintro attemps to provide a simple gtk api similar to maybe Python or Ruby, so
the user will be able to just allocate a surface and a cairo context, and
> Are you familiar with GTK and cairo?
No I'm not. I am quite familiar with C/C++ FFI, ref and ptr though in high
performance context where allocation is very expensive (GPUs memory allocation)
and the GC is a bottleneck.
In short, for a local variable, I have the following strategies:
> Shouldn't context stay a ref object?
Are you familiar with GTK and cairo?
Well ref object without GC may be fine, but I think that is still work in
progress for Araq, and I have to learn that then.
But destructors work already, as they are used for seqs and strings, and it is
my feeling
Shouldn't context stay a ref object? It's not a type that you can trivially
copy (i.e. it's a resource like memory, a socket, a file handle, not an integer
or string).
Replacing finalizers with destructors for gintro seems to work in principle, at
least I got cairo_anim.nim running with a few hacks.
Problem is similar as with finalizers -- for callback vars owned by gtk we do
not want a finalizer or destroy call, while for ordinary use we want the call.
For
