Allright, I did some more test and I'm not sure I understand handles properly.

Lets assume code:

class Foo{ int a = 0; }

Foo foo();:

then:

1. Foo@ h = @foo -> it creates a handle that points to "foo" instance, so it also increases refcount, right? But what is the refcount now? Is there a way to check refcount of asIScriptObject for debugging purposes?

2. h.method() will execute method on object "foo", but what about @h.method() ? Both seem to work, but is it allright?

3. @h = foo or @h = @foo ? Documentation uses second with @ prefixing the object instance, but both seem to compile and work?

4. When accessing object's properties through handle, again - @h.prop or h.prop?

I'm a bit confused by this notation and I'm not sure when the handle is really a handle, when object is really an object and what happens when I add/skip @ prefix.

This leads me to a weird problem with my function that takes "?&in" generic parameters. When I pass a handle to it like this:

Foo @h = foo;

my_func(h); // assuming my_func(?&in) on C++ side

it tries to create a temporary copy of object Foo, instead of passing a "handle" type to the call. Which completly undermines what I understand about how to refer to a handle and how it works. If "h" is not a handle but the object, then why I can pass it like the above example to any script function for example:

Foo @h = foo;

my_script_func(h); // with my_script_func(Foo@)

When I changed my_func(h) to my_func(@h) it seems to work, but then I have no idea what is really passed there. Isn't @h a handle of a handle, since h is a handle, not an object? And when really passing handle, why does it think it's actually an object Foo, not a Foo@ handle and tries to copy the object, not the handle?

PS. I'm starting to think that h doesn't really refer to a handle, but the object, unless I prefix it with @h which then means the "handle to object"? So even though I declare it Foo @h, but then use it as just "h" I'm really refering to the object itself? So handle is handle only when @h is used, and that's why it complains when I pass just "h" to a function, because it's basically the same as passing "foo" object? Is this correct? And if so, what does @h.a mean when I access property. Shouldn't this throw some error that I'm accessing a handle, and force me to use h.a syntax?

1. yes. h will hold a reference to foo, and thus increase the ref count. You can inspect the value of the ref count by calling AddRef() and then Release(). Both methods return the refcount.

2. @h.method() would mean "call method() on the object referred to by h, and then take the address of the returned type". I should probably add a warning, if the @ symbol is used in cases like this.

3. If the left hand expression has the @, then the compiler already knows that the right hand expression also must be operating on the address, so it implicitly adds the @ if it is not there.

4. Same thing as 2

5. Think of the @ operator as "work on the address of the object". When not using the @ operator you will be working with the actual object, not it's address. That's why when calling my_func(h) makes a copy of the object to pass into the function (since the argument is &in), but my_func(@h) passes in the address of the object.

You can also think of the @ symbol as being closer to C++ & symbol, except a variable declared as & cannot be reassigned after initialization.

The weakref type currently doesn't have a copy constructor or assignment operator. That's why it doesn't allow you to pass this type by value. I'll have this implemented.

I've implemented this in revision 2340.