..or something similar with a better name. Basically just telling the parser to substitute '[' ']' for the actual "opIndex(..)" defined method.

I noticed the current behavior for opIndex allows overloads.


r = engine->RegisterObjectMethod("Array<T>", "T &opIndex(uint)", asMETHOD(ScriptArrayTemplate, At1), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Array<T>", "T &opIndex(uint,uint)", asMETHOD(ScriptArrayTemplate, At2), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Array<T>", "T &opIndex(uint,uint,uint)", asMETHOD(ScriptArrayTemplate, At3), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Array<T>", "const T &opIndex(uint) const", asMETHOD(ScriptArrayTemplate, At1), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Array<T>", "const T &opIndex(uint,uint) const", asMETHOD(ScriptArrayTemplate, At2), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectMethod("Array<T>", "const T &opIndex(uint,uint,uint) const", asMETHOD(ScriptArrayTemplate, At3), asCALL_THISCALL); assert( r >= 0 );


However right now they can only be properly accessed by writing out the full method in the script. Is this intended?


//as script
Array<int> a;
a.opIndex(1,2) = 3; //ok
a[1,2] = 3;//error

..could be rewritten as this with an engine property flag:
a.opIndex(1,2) // '[', ']' have been expanded to the actual method

//maintain compatibility
Array< Array<int> > a2;
a2[1][2] = 3; //a2.opIndex(1).opIndex(2)
a2[1,2,3][4] ...


Thought it worth mentioning as it seems like it would be really easy to implement and wouldn't break backwards or forwards compatibility between angelscript versions and gives a nice C# like array syntax if desired.

Cheers.

edit: Didn't want this to sound like a request, just something to add if you think it's a good idea.

edit2: Actually put this behavior in using the pre-compiler (equivelent of CScriptBuilder), which simply replaces "[]" tokens with the full "opIndex()" declaration . Works great.

I actually already have been thinking about allowing opIndex to be used with multiple arguments, and even non-integer arguments, like strings. I don't know when I'll be able to get it done though.

Non-integer indices could be great for associative arrays. I had actually been looking at how a more generic array type *cough*universalbaseclass*cough* could be implemented with the existing array.