I am not sure if what you suggest is right. Please review this example:

package
{
	import flash.display.Sprite;

	public class ToStringTest extends Sprite
	{
		public function ToStringTest()
		{
			var o : Object;
			o.toString = 1; //is correct and compiles well
			
			toString = 1; // is wrong, will not compile
		}
		
		override public function toString() : String
		{
			return super.toString();
		}
	}
}

So... class Object does not contain the method "toString" (not as in Java). You can add "toString" as an "int" to a dynamic object. However, if FDT would bind "toString" to a dynamic object, then it would cause an error at "o.toString = 1". So, from a semantic point of view, the FDT behavoir is right.

FDT could add "toString() : String" to autocompletion, but I think it's not correct to give proposals that are in fact not right.

Any thoughts on this?

Greets, Nico.

package
{

	public class XXX
	{
		override public function toString() : String {
			return "XXX";
		}
	}
}

The code above will also not compile. So the compiler is very clear about this, however the Flash VM, interpretes toString on serveral occasions. But that's a different story...

1) Dynamic classes like {} have the "toString" property ALWAYS assigned. If not overwritten (like in your example) it contains a function. So the chances are quite high toString contains a function in dynamic objects. It will be the case usually. If toString is certainly defined then toString is for sure. Never the less I think a .toString code-completion has a 99.9% chance of being useful.

2) Normal classes that don't have a toString property/method defined do have the Object's toString method.

That concludes to me:
With normal classes its clear: toString exists and if not defined differently its a function without parameters.
With dynamic classes the method exists and I would offer code completion to a method but I would show a warning stating that accessing these methods might conflict with different use and I would make a switch in the FDT Problems dialog.

And not to forget: the other methods are not really less important

var foo : EmptyClass = new EmptyClass();
trace (foo["toString"]); // returns function
trace (foo.toString); // does not compile
			
var a : Object = {};
trace (a.toString); // return function

So... at runtime "toString" always exists. But it will only compile:

• with typed objects instanciated from a "dynamic" class
• if the type cannot be resolved (array access, star type, no type) - as you wrote in the first place.

Only on those occasions FDT should propose "toString". So "toString" cannot be added to Object (because of inheritance), but to "dynamic or untyped objects".

You are right - it makes sense to add a special problem for that in order to switch it off - maybe that can be default.
Problem Text could be: "Method toString() might conflict with different use in this object".

Thank you for clarifying that!

Greets, Nico.