It appears that in the array addon, the "length" accessors have been replaced by "size". It's indeed a good idea to have all containers use the same syntax. However, why not keep the old length accessor as well? Otherwise all existing code referring to the length property is broken.

I suggest that you simply keep both, to maintain compatibility:

	// Register virtual properties
	r = engine->RegisterObjectMethod("array<T>", "uint get_length() const", asMETHOD(CScriptArray, GetSize), asCALL_THISCALL); assert( r >= 0 );
	r = engine->RegisterObjectMethod("array<T>", "void set_length(uint)", asMETHODPR(CScriptArray, Resize, (asUINT), void), asCALL_THISCALL); assert( r >= 0 );
	r = engine->RegisterObjectMethod("array<T>", "uint get_size() const", asMETHOD(CScriptArray, GetSize), asCALL_THISCALL); assert( r >= 0 );
	r = engine->RegisterObjectMethod("array<T>", "void set_size(uint)", asMETHODPR(CScriptArray, Resize, (asUINT), void), asCALL_THISCALL); assert( r >= 0 );

What do you think?

By the way, this also applies to the stdstring addon (for which length actually seems more appropriate to me than size anyway ? ).

With the refactoring of the symbol lookup it is no longer allowed to have the same symbol match more than one different entity. size can not be both a method "size()" and virtual accessor "get_size()". 

Unfortunately it won't be possible to maintain backwards compatibility in this case. 

So you mean that we have to choose between the length() function and the get-length accessor then?

I have tried the patch suggested above and it works fine so I am not sure to understand.

Yes.

It currenty doesn't give an error if you register both length() and get_length(), however when compiling expressions with length the symbol will only match the accessor, so the length() method becomes unaccessible. As such any expression that tries to call length() will give an error.

Thanks, it makes sense. I guess I'll have to get rid of the length() method then, as I definitely do not need it! Why this choise of keeping the length function and changing the property to "size" by the way? It looks like it will also break for people using the stl style.

I didn't give it much thought. I had to make a decision, and naturally I decided according to my personal preference (which is to use length()).

Sometime in the future I will review all the method names of the add-ons and change them to be consistent throughout. 

I changed the name of the property accessors back to the original, however now they will only be registered if you define AS_USE_ACCESSORS 1. In this case the the length() method won't be registered to avoid the conflict.

I hope this works for you.

This is available in revision 2538.

Thanks! This is more than great!