A bug! or atleast something that shouldn't be possible....

#1 Eek found another one..

GuiFilterCtrl.cpp which is based off of GuiControl has a console method defined as

ConsoleMethod( GuiFilterCtrl, setValue, void, 3, 20, "(f1, f2, ...)"
              "Reset the filter to use the specified points, spread equidistantly across the domain."
			  "@internal")

GuiControl has a DefineEngineMethod for setvalue

DefineEngineMethod( GuiControl, setValue, void, ( const char* value ),,
   "Set the value associated with the control.\n"
   "@param value The new value for the control.\n" )

If I call it w/ just one parameter, which one does it use?

#2 Wait... that's not all

guiInstpectorTypes has a console method defined as

ConsoleMethod( GuiInspectorTypeFileName, apply, void, 3,3, "apply(newValue);" )

But... the class is derived from field.cpp which also has it defined as

ConsoleMethod( GuiInspectorField, apply, void, 3, 4, "( string newValue, bool callbacks=true ) - Set the field's value. Suppress callbacks for undo if callbacks=false." )

#3 I wish I was done...

guiPopUpCtrl has

ConsoleMethod( GuiPopUpMenuCtrl, add, void, 3, 5, "(string name, int idNum, int scheme=0)")

but is derived from simSet which also has it defined

ConsoleMethod( SimSet, add, void, 3, 0,
   "( SimObject objects... ) Add the given objects to the set.\n"
   "@param objects The objects to add to the set." )

#4 Since ambiguity is so rampant in this engine, I am starting to think that there is a "new" functionality going on here. As in, when a derived class redefines a previously existing function it overwrites the entry point. So any console method defined on the base object become inaccessible to the derived object's ability to call through the console.

That or no one ever gave a crap about it cause it "kinda" worked. Who cares about performance.....

Hope someone knows the answer.

#5 This works as designed. When using a method the TorqueScript subsystem resolves the call by looking up the method in the object's defined methods then through the parent class methods and all the way up to the base class methods. If none match then you get an error like so:

==>2007.doesnotexist();
<input> (0): Unknown command doesnotexist.
  Object (2007) GuiButtonCtrl -> GuiButtonBaseCtrl -> GuiControl -> SimGroup -> SimSet -> SimObject

It says it looked up GuiButtonCtrl then GuiButtonBaseCtrl then etc.. until hitting the last class in the hierarchy SimObject.

You have to keep in mind that TorqueScript was designed to be as simple as C but with some C++ classes support and that includes methods acting as virtual functions in the lookup.

#6 Ok, so it is doing what I thought, it allows you to re-define a console method in a later derived class.

and there would be no way to call the function from a parent class from the derived object unless the parameters didn't match.

Correct?

#7 Umm, maybe not.

You could try this:

$object = new GuiTreeViewCtrl(); // with whatever is needed to make it
SimSet::sort($object, < other params >);

You just have to give it the equivalent of the 'this' pointer if I remember right.

Also, C++ does the exact same thing with virtual functions. It has to decide at 'runtime' which function to call. This can get really expensive when you have multiple or diamond inheritance. Now, this may have changed as compilers have gotten smarter, but I think some of this is still going on.

I have found out some interesting things about packages as well. If you look at the documentation in the Torque Script Manual it says it will unregister packages higher up in the chain if you unregister one in between. However, it doesn't do it. At least what I tested did not do it. The function I was testing continued to call the last registered package, even though one in between was unregistered. Then I unregistered the last package and the intermediate one was gone as expected. So that documentation about Packages in the script manual is not correct. If someone wants to test this I can rig up a test script for you. I will have to do this to get the docs changed anyway.

#8 You could also use the Parent namespace if you're inside a function of the object in question and want to do the override, something like:

%object = new GuiTreeViewCtrl(); // with whatever is needed to make it  
%object.doSort();

function GuiTreeViewCtrl::doSort(%this)
{
   Parent::sort(%this, < other params >); 
}

Interesting on the package inheritance stuff Demo, I hadn't messed with packages much yet myself, so I hadn't run into that. Something to take note of/track down eventually.