To be honest? I don't see the point, either. This makes sense for low level stuff, like passing around pointers for ints in C, but BGT would be just fine—nay, better off—if it was just assumed implicitly that a reference to an object is it's handle unless there is explicitly an oppAssign method defined. When would you not use handles? It's derived from C, sure, but in practice, all it does is make for extra typing and more tedious porting.
Compare with Java, where all objects are treated as pointers, all primitives are treated as values, and references and syntax and dotting are accordingly simplified. (Except for Strings, but those are always special cases.) I think the majority of the time spent porting my games from Java to BGT was arranging all those @ signs, and parentheses, because how do those fit into order of operations, anyway? And the main thing holding me back from porting BGT games to other languages is that I'd have to either write a script to remove every single @ and its parentheses, or do so by hand. ... Also how Python made the terniary operator b if a else c, and everyone else ever made it a? b : c, but I digress.
So, if you're using objects in BGT, use @ signs. An array of objects? Object@[]. A function that takes/returns objects? Object@ myfunc(object@ param). Class properties? @. Comparing objects? @a==@b. Dictionaries? Use @ even more. BGT dictionaries are in desperate need of wrapping in something less cumbersome.
The only weird thing is that you can do this: @a=b, or call that function from earlier like @a=myfunc(b). So I guess you only use @ on the right side for comparisons and dictionaries? Why? I don't know, but those operations do seem kinda special in this regard, so whatever.
Basically, you have to say @a=b, because just a=b tries to change a (the object). Except you can't do that anyway without opAssign, because BGT objects are not C-style structs, so there is no default for a=b. You're almost never working with objects directly, just pointers. It's through properties and methods that you can affect the underlying data,. You'd think this would mean you would only need the @ for opAssign, but I did not develop Angelscript and I do not know C++ and I'm probably missing something obvious to a CSmith.
So. Your example.
sound@ mysound=synth.write_wave_sound();
Or if you're assigning it to a pre-existing sound:
sound@ mysound;
@mysound=synthwrite_wave_sound();
This is why BGT desperately needs a the "new" keyword, or some equivalent. either that, or to just throw the handles under the hood. -_-
Even better: vectors do not take handles well. So they work more intuitively, unlike sounds or dictionaries.
看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
George... Don't do that.