I would like to ask for your opinion on what I should name the new generic handle type, that I will implement for release 2.21.1. Let me first explain what this new type is:
The generic handle type is a new data type that is able to store a handle of any reference type. This is different from the 'any' type, which can store both handles and values. The generic handle type also have the benefit of using an intuitive syntax, i.e. you store the handle in the type through a normal handle assignment, and you retrieve the handle from the type through a cast operation. The type also permits you to do handle comparisons with the 'is' operator. To the script writer the type will look like it is the base type of all reference types or perhaps better a common interface that all reference types implement (both script classes and application registered types).
// Example usage (here I've used the name 'ref' for the generic handle type)
// Declare the variables
object @o = object();
ref @r; // It's not allowed to declare the type without the @, as it doesn't make sense in this case
// Store a reference to 'object' in the generic handle
@r = o;
// Determine if the reference is pointing a specific object (also works with '!is')
if( r is o ) { /* do something */ }
// Cast the handle to the desired type (returns null if the stored type is not compatible)
@o = cast<object>(r);
// Clear the handle
@r = null;
Now, my dilemma is what I should name the type. I have a few different ideas, and would like to hear your opinions in order to choose the best.
'ref' is the currently what I like best, as it is short and clearly indicates that it is a reference to something.
'handle' would serve the same purpose as 'ref', and would be in line with what a handle is in AngelScript.
'object' would give an indication that it is a base type, which it isn't. In some cases it doesn't make as much sense to say a type is an object, e.g. an array, would you say an array is an object? Also, the name 'object' is quite often used by the application for other purposes.
'unknown' is also appropriate, as it is not known beforehand the real type of the reference stored in the type.
Let me hear your opinions, or perhaps suggestions for a completely different name.
Of course, this type is once more not a built-in type, but rather registered by the application with a pre-implemented add-on, so if you do not like the name I chose in the end you are always free to use something else (or perhaps not include the type at all).