void handles/pointers as used in C/C++ will not be allowed, as they are not typesafe. However, I do want to improve the support for dynamic types, like the CScriptAny. The any type can already store any type safely. The only problem with it is the rather awkward syntax of storing and retrieving the stored value.

It should be possible to implement a ref cast behaviour that receives the desired type as a hidden parameter (similar to the variable arg ?). This would then allow the container to return the handle of the right type, or null if it is not supported. If (when?) I implement this it should be possible to use the any type as follows:

{  CObject @obj;    // Store the handle of an object in the any container  any c;  c = @obj;  // Retrieve the handle through a ref cast  @obj = cast<CObject>(c);}

Maybe the current CScriptAny type is not the most adequate for this usage. Perhaps something a bit most specific, like a generic handle type so it can be seen as if it was just a handle, thus allow handle assignment to work as it should. It would be necessary to allow the registration of a specific behaviour that overloads the handle assignment operator, and probably also the handle comparison operators. Likewise, another type more directed towards value types may be needed.

Something else that might help for variant types would be an overload for the "." operator, similar to overloading operator-> in C++. This would make the variant type even more intuitive to use.

{    var obj; // I renamed mine to var. "any" just sounds awkward to me =/    obj = new Class();        obj.SomeClassMethod(); // overloaded to invoke whatever method}

The operator could pass the function ID of the called method, a list of parameters, and the number of parameters. The class would be responsible for invoking it correctly.

Or is that too much like &#106avascript? =p<br><br><!--EDIT--><span class=editedby><!--/EDIT-->[Edited by - _orm_ on October 29, 2010 10:53:44 AM]<!--EDIT--></span><!--/EDIT-->

That's a dispatch mechanism. The true function that will be called would have to be matched at run-time according to the type of the argument expressions. The performance of these calls would obviously be many times worse than ordinary calls determined at compile time.

This is also on my to-do list, but it is extremely low priority.