Crashes when using name SimObject
by BlueRaja · in Torque Game Builder · 07/28/2008 (1:53 pm) · 6 replies
$blah = new SimObject(SimSet); //Fine, SimObject is parent of SimSet $blah = new SimGroup(SimSet);//Displays an error, SimGroup is not parent of SimSet $blah = new SimSet(SimSet); //Displays an error, SimSet is not parent of SimSet $blah = new SimObject(SimObject); //Program freezes! $blah = new SimSet(SimObject); //Program freezes!
About the author
#2
You cannot give a SimObject a name that conflicts with a Torque object type. Still it would be better if the code failed gracefully with an appropriate error message and not just freeze.
07/28/2008 (2:08 pm)
That's a known limitation of the scripting system. You cannot give a SimObject a name that conflicts with a Torque object type. Still it would be better if the code failed gracefully with an appropriate error message and not just freeze.
#3
James: I'm writing a mocking framework for TorqueScript to coincide with TUnit. As such, I need to be able to take the name of a class or namespace - including SimObject - and mock it.
My solution was simple enough:
07/28/2008 (7:50 pm)
Tom: What do you mean? new SimObject(SimSet) works fine and as expected (ie. the same as new SimSet()), and giving other objects other known names (see the examples in the first post) works or fails gracefully as appropriate. It's only when giving an object (of any class) the name "SimObject" that it freezes.James: I'm writing a mocking framework for TorqueScript to coincide with TUnit. As such, I need to be able to take the name of a class or namespace - including SimObject - and mock it.
My solution was simple enough:
if(strlwr(%mockClass) $= "simobject") %mockClass = ""; %mockMe = new SimObject(%mockClass);However, given the behaviour of all other names besides SimObject (and the fact that the program crashes), this is definitely a bug, which is why I'm sharing it.
#4
[reads wikipedia] .. so after you have this new mock SimObject(SimSet), what can you do with it ?
couple side notes - i believe the $= operator is case-insensitive, so no need for the strlwr there,
and you might be assuming a robustness on the part of TorqueScript which it just doesn't have. This seems like a job for C++ more than Script. Have you looked at modifying the ConsoleObject declaration macros to automatically create mock objects for you ?
07/28/2008 (10:24 pm)
Quote:I'm writing a mocking framework for TorqueScript to coincide with TUnit. As such, I need to be able to take the name of a class or namespace - including SimObject - and mock it.why not just say its parent class dresses it funny and let it go at that ?
[reads wikipedia] .. so after you have this new mock SimObject(SimSet), what can you do with it ?
couple side notes - i believe the $= operator is case-insensitive, so no need for the strlwr there,
and you might be assuming a robustness on the part of TorqueScript which it just doesn't have. This seems like a job for C++ more than Script. Have you looked at modifying the ConsoleObject declaration macros to automatically create mock objects for you ?
#5
07/29/2008 (12:16 am)
Is it really necessary to have a mock object rather than a "real" one for the purpose of these tests? If you just don't want to pollute your "real" class namespaces with test related methods you could, as an idea, put them inside a package which you activate/deactivate.
#6
Thanks for the heads-up about the $= operator!
James: Mock Objects are extremely important for Test-Driven Development, and even just for Unit-tests in general. The reason is that when writing a unit-test, you want to be testing just a single unit (class). However, if your class uses other classes, then your test may very well be relying on the assumption that those other classes work perfectly; thus, a bug in a completely different class could cause the unit-test for this class to fail! This is the beauty of mock-objects - you can test your class in complete isolation from every other class so that when a test fails, you can be sure that it's because of your class and not any others.
There are other reasons to use them as well.
As for the packages: I considered it, but decided against it because it was just more code, and these new 'polluting' namespaces will only be added when the tests are run (which doesn't happen during the normal course of the game). If I find that having so many namespaces does adversely affect running the tests, however, I can still implement the packages-idea rather easily.
07/29/2008 (7:08 am)
Orion: I already have it pretty much done, all in script :) just need to test and clean it up a bit before I release.Thanks for the heads-up about the $= operator!
James: Mock Objects are extremely important for Test-Driven Development, and even just for Unit-tests in general. The reason is that when writing a unit-test, you want to be testing just a single unit (class). However, if your class uses other classes, then your test may very well be relying on the assumption that those other classes work perfectly; thus, a bug in a completely different class could cause the unit-test for this class to fail! This is the beauty of mock-objects - you can test your class in complete isolation from every other class so that when a test fails, you can be sure that it's because of your class and not any others.
There are other reasons to use them as well.
As for the packages: I considered it, but decided against it because it was just more code, and these new 'polluting' namespaces will only be added when the tests are run (which doesn't happen during the normal course of the game). If I find that having so many namespaces does adversely affect running the tests, however, I can still implement the packages-idea rather easily.
Associate James Ford
Sickhead Games