Scriptobject inheritance; what caveats?

#1 An unrelated issue. This code returns a broken object- it may not be able to call it's parent classes functions. Accessing the namespace before the class is instantiated once seems to be what breaks it. (there is a forum article about this somewhere, I think- I didn't bookmark it though.

function MLBalloonsLevel::create()
{
	return new ScriptObject( MLBalloonsLevelObj : MLGameLevelObj )
	{
		superclass = "MLGameLevel";
		class = "MLBalloonsLevel";
		levelName = "Balloons!";
	};
}

This code returns an OK object; it can resolve it's parent classes' functions. By moving the factory function outside the MLBalloonsLevel:: namespace, it works around the problem.

function MLBalloonsLevel_create()
{
	return new ScriptObject( MLBalloonsLevelObj : MLGameLevelObj )
	{
		superclass = "MLGameLevel";
		class = "MLBalloonsLevel";
		levelName = "Balloons!";
	};
}

#2 When you mentioned inheritence in the other thread, I incorrectly assumed you were talking about C++ side inheritence, so some things to keep in mind:

--Torque Script is not oop, it's oop-like, in that you can share namespaces with "parents", and have script functions grouped into namespaces that "just happen" to be the same as the object's type. That gives the implication (and in most cases the actual ability to utilize) objects with a sort of inheritance/polymorphism, but it's not in any way going to react in all ways how you would expect a fully oop language such as c++ to act.

--What you are calling inheritence here is actually a type of concatenation--when you define two objects in the ScriptObject params, it is basically simply using both of those for creating the namespace that you are looking at in reference to later use of that object.

More accurate/expected behaviour in an oop-like fashion may very well be a worthy goal of T2D (I'm not on that team, so I honestly cannot say for sure), but currently I think that you are expecting a bit more out of the oop-ness of script objects than exists, which may be why you are running into problems here. If you are absolutely sure that you do need this type of oop-ish behaviour, it may make sense for you to implement each of your objects in C++, provide the normal methods for script access to the objects, and keep the oop-ishness (is that a word?!) "under the covers" of script (handle it in the engine side of things).

Finally, there does exist a resource by Bryan Edds that gives more oopish-ness to objects than stock Torque (or is this what you are using? I'm not sure to be frank), that may be the way you want to go instead.

Of course, please keep in mind that I'm more of a TGE guy than a T2D guy, so if any of the above is incorrect someone else please step in and correct me :)

#3 Thanks Stephen; I have seen Bryan's OOP Torquescript resource but am not using it, yet. I wanted to make sure I understand how things are working in the Torque core.

It seems to work as expected for 2 levels of inheritance, or concatenation, as you say. If that pans out might just keep a 2 level heirarchy because I try to avoid C++ and getting into the engine code.

#4 Yeah quite honestly I think that you are trying to stretch TorqueScript oop-ishness beyond it's limits (not that your intent is bad or anything, just that the implementation isn't up to it/really designed for it).

#5 @Stephen, and anyone else from GG listening.

Honestly this has been rather frustrating in getting to know torquescript. This is not my first programming language- I am familiar with C, Objective-C, Java, Perl, Python, PHP, Javascript. Notice all those dynamically typed scripting languages there ;-) I feel like I *should* be right at home with torquescript but I am not. I guess I am expecting it to be a full fledged programming language, but it is not.

The torquescript manual should clarify what it can and cannot do vis-a-vis OOP.

The torquescript manual should clarify where it's like a full fledged programming language vs. where it's features are driven by core engine features, or performance reasons, etc.

The difference between the "namespace" and the classname and superclass is still lost on me, and I've been banging away at this for months. Maybe I will scrap inheritence and try to use packages instead ... I don't know yet

A lot of stuff with torquescript is dead simple and easy to understand.- everything is a string, objects can have names or integer handles, it compiles to bytecode, etc. Pretty easy to start working with. That's really great and will really allow lots of people to get their hands wet and start writing games. Torquescript fits that bill perfectly.

Then you start trying to do something like make a set of classes that inherit or implement a common interface and wham it's no longer fun, at all.

Have you ever seen or written object oriented Perl? It's really really ugly, and it just feels wrong also- you can tell that everything is just an anonymous hashtable variable masquerading as an object.

Same thing with torquescript- the OOP-ishness is just a gloss, it's not OOP to the core, and when you try to program that way, it doesn't feel right.

This is from the "Features we need" section of the Torquescript manual:

Quote:
Object-oriented functionality - Object-oriented programming has been a revolution in the art and science of software engineering. Scripting languages which provide object-oriented functionality offer many benefits, including:

* Encapsulation- Provide a means of limiting access to code and data.
* Inheritance- Provide a means of creating new 'objects' from engine objects and/or scripted objects.
* Polymorphism- Allow us to over-ride the default behavior of derived object code, whether the object is derived from engine objects or other scripted objects.

Why is that passage even in there? If torquescript can't live up to the "wish list" as stated by it's own developers... I don't know. Bryan Edds said that there has been a lot of negativity toward his OOP resource from the GG staff. It's dissappointing to hear. But I am not going to go there; I got to learn to pick my battles.

But anyways Stephen, thanks for your comments above they were helpful.

#6 Not sure if this helps (or if you've seen this already) but here is an example on how I've used "inheritance" in TorqueScript







Script objects also have three levels of inheritence... say we created a base class like this
and add some starting values to it

function createEntityClass()
{
   new ScriptObject(Entity){
      health = 100;
      mana = 250;
      strength = 10;
   };
}

now lets make our own onAdd function attached to this "Entity" object which will get called everytime an entity is created...

function Entity::onAdd(%this)
{
   echo("New Entity added -" SPC %this.getName());
}

then we can create a child class of it, like this

function createOrcClass()
{
   new ScriptObject(Orc) {
      class = Entity;   
   };
   Orc.health = Orc.class.health + 50;
   Orc.strength = Orc.class.strength + 5;
}

(I did the health and strength that way so it would build off of its class)

run the createEntityClass(); function in the console and you should see this

Quote:
New Entity added - Entity

then you should see this in the console when createOrc(); function is run

Quote:
New Entity added - Orc

now you can create a function like this

function createOrc(%name)
{
   new ScriptObject(%name){
      class = Orc;
      superClass = Entity;
   };
}

then just call it like this

createOrc(Bob);

and if you want to overide the entity onAdd you can do so by adding one to Orc

function Orc::onAdd(%this)
{
   echo("New Orc of added -" SPC %this.getName());
}

and it will fire when you create an orc

now to test this add

function Entity::yell(%this)
{
   echo("This yelled -" SPC %this.getName());
}

then whatever orcs you created with "createOrc" call ".yell();" on them and you should see the console react properly

#7 Thanks Matthew; that helps to see a 3-level inheritance going on.

In your example, I noticed that here you did not write "class = Entity;" at the top of your heirarchy:

function createEntityClass()
{
   new ScriptObject(Entity){
      health = 100;
      mana = 250;
      strength = 10;
   };
}

Yet later you instantiate the Entity class

new ScriptObject(Orc) {
      class = Entity;   
   };

The object name / class name / namespace concepts are all convoluted. Are they really the same thing? The torquescript syntax tries to differentiate them, but on the backend they are all just munged together it would seem.

#8 One other confusing thing: Why is it this:

new ScriptObject(Orc) {
      class = Entity;   
   };

Instead of

new ScriptObject(Orc) {
      SUPERclass = Entity;   
      class = Orc;
   };

#9 The name of an object is automatically added to the Namespace

[code]
new ScriptObject(Orc) {
SUPERclass = Big;
class = Ugly;
};
[code]

Will give you a namespace path of:

ScriptObject->Big->Ugly->Orc

If it can't find a function in Orc, it will move to the parent Ugly, then to the parent Big, and finally to ScriptObject

#10 OK, lesson learned for me: when trying to figure out inheritence in torquescript, just use trial and error until the namespace path reflects what you are trying to do. For example, this code errors out with "cannot change namespace parent linkage for ChildThing from ParentThing to ScriptObject"

echo("creating ParentThing...");
new ScriptObject( ParentThing ) {};
ParentThing.dummyFunction();

echo("creating ChildThing...");
new ScriptObject( ChildThing ) {  class = ParentThing; };
ChildThing.dummyFunction();

echo("creating GrandChildThing...");
new ScriptObject( GrandChildThing ) { class = ChildThing; };
GrandChildThing.dummyFunction();

Console output (i am calling dummyFunction to get the engine to print the namepace path)

Quote:
creating ParentThing...
T2D/client/test.cs (0): Unknown command dummyFunction.
Object ParentThing(1244) ParentThing -> ScriptObject -> SimObject
creating ChildThing...
T2D/client/test.cs (0): Unknown command dummyFunction.
Object ChildThing(1245) ChildThing -> ParentThing -> ScriptObject -> SimObject
creating GrandChildThing...
Error: cannot change namespace parent linkage for ChildThing from ParentThing to ScriptObject.
T2D/client/test.cs (0): Unknown command dummyFunction.
Object GrandChildThing(1246) GrandChildThing -> ScriptObject -> SimObject

But, throwing a bogus "superclass" in there seems to work around the issue and give the namespace path I am seeking:

new ScriptObject( GrandChildThing ) { superclass = ParentThing; class = ChildThing; };

Quote:creating ParentThing...
T2D/client/test.cs (0): Unknown command dummyFunction.
Object ParentThing(1244) ParentThing -> ScriptObject -> SimObject
creating ChildThing...
T2D/client/test.cs (0): Unknown command dummyFunction.
Object ChildThing(1245) ChildThing -> ParentThing -> ScriptObject -> SimObject
creating GrandChildThing...
T2D/client/test.cs (0): Unknown command dummyFunction.
Object GrandChildThing(1246) GrandChildThing -> ChildThing -> ParentThing -> ScriptObject -> SimObject

#11 Would you say are more torque developers using PACKAGES to modularize their code, or are more using class inheritance to modularize their code? Or both (yikes!) ?

I guess I am on the fence still for my own scripting.

#12 Remember that packages wrap functions only. They allow you to define multiple foo() functions that do something different based on which package is active. There really isn't a way to tie a package to a script object. I suppose you could potentially tie the two together in a logical sense, having packages of functions setup to basically serve as public and private methods of an object, but I think keeping that straight in your head would be a nightmare.

Personally for me, I've found that the best way for me to keep the very global nature or Torque Script straight in my head is with directory structure of the files themselves (probably a hold over from my Java programming), and using packages to wrap logical functions. For instance I have a GG Logo package, that handles the display of the GG logo at the beginning of my game, and then I have a Main Menu package that handles the functionality for the main menu.

It certainly does take a while to get to terms with Torque Script, but if you give it enough time, it will all click together, and you will begin to see how you can formulate and organize everything to help you keep it all ordered...

I hope some of this is of some assistance...

#13 Eric- thanks for feedback.

Quote:if you give it enough time

today I feel like I failed the 1st grade and am being sent back to kindergarten, trying to figure out this stuff which I thought I already understood months ago about torquescript.

#14 Again (not trying to force this down your throat, but I think it might have gotten glossed over since I was running out of time this morning and didn't get to respond to the thread)...it may just make sense to build your inheritence tree in C++, by making a set of objects there, and then creating accessor methods as appropriate for what you need to do.

As you mentioned above, TorqueScript simply isn't true oop--and if you really do need true oop, I personally would implement the objects in c++ and then just use them from script.

Not a perfect answer I know, but you've hit upon one of the areas that people don't go often in Torque/TorqueScript--mostly because there are other ways of doing it.

I myself would love to see TorqueScript fully oop, but it's one of those "nice to have things" instead of those "must have last week" things for a large majority of the Torque users. I fully admit T2D, being so focused on having everyone use script as much as possible, changes this priority, but it will take quite a bit of time and resources to not only make TorqueScript fully oop, but also not break it for the rest of the integrated platform and existing products...and I quite honestly have no idea if/how/when/why it will or will not happen...so once again my suggestion is it might be in your best interest to find an alternate implementation strategy.

#15 @Stephen, Do users find other ways of writing their game mods because the OOP is difficult and/or broken in torquescript, or because they don't want OOP in the first place? Not everyone is so vocal as guys like Bryan Edds, or myself.

The only way to tell would be to poll torque licensees. That would be an easy yes or no poll.

Quote:Would you like to see improved object oriented programming features (x, y, z) in torquescript? YES/NO/DONT CARE.

Would it have been easier to write your game if such features were available? YES/NO/DONT CARE.

Bonus question: How long does Pickle Relish last in the fridge? 1 week /10 weeks / 4 years

My vote: YES, YES and 4 years.

However, I don't see this kind of thing happening; I get the impression that torquescript is just the way it is and the Torque dev team is not interested in making changes.

Also a factor could be that the demo mods don't use OOP, that I have seen; instead they use PACKAGE. So new users just emulate that when they are getting started.

Or like Eric Armstrong, they are Java programmers and see the "package" keyword and think must be the ticket.

However, I do have a working solution that basically revolves around inspecting the namespace path at runtime (thanks Labrat for the reminder) and tweaking my "new scriptobject" calls until the namespace path is correct. The syntax does not make sense and is inconsistent! But it doesn't matter it works now and that's all I care. I keep encountering weird stuff, like having to pass %this when calling a Parent::function(), but I just work around it.

#16 From Ben Garney's .plan back in December of last year, which asked for additions/modifications of TorqueScript, and some of the things that were announced at either IGC and/or Torque Boot Camp--Indie Style:

Oop-ism was suggested by one person out of all of the posters (Ed Maurina), and as it turns out his specific example at least wasn't working only because he had a typo in the script.

Inheritence issues were discussed very briefly in one response, but only in relation to a reason for why something was being modified.

I didn't add up the exact numbers/percentages, but based on what I've seen from the last two major events (IGC and TBC-Indie as mentioned above), roughly 80% of the changes requested have been implemented.

So no, I would basically say that no one else has really worried about the oop-ish ness of Torque Script.

Again, I will certainly agree that the more focus on doing everything in script due to the EA release of T2D has changed the nature of Torque Script's needs, and I would certainly suggest that future TorqueScript functionality enhancements will have a very strong look taken at increasing oop-ness, but I can also say that will be well in the future.

EDIT: Please note by the way that all of these changes I am talking about are in TGE 1.4 RC2, and once TGE 1.4 is in final release, the changes that are appropriate for both TSE and T2D will be moved to those products respectively.

#17 I really struggled to learn TorqueScript myself, because I was confused by the OOP terminology applied to a non-OOP language. In the end, I created a set of factory functions (one for each "class" of object in a shallow hierarchy) to handle the "OOP" for me. In other words, call something like

%obj = factory.newFooObject( %subclass, %instance, %etc );

and let that function fill in the class, superclass, etc and do sanity checking.

#18

Quote:So no, I would basically say that no one else has really worried about the oop-ish ness of Torque Script.

I am sure you took a statistics class in college right? If you do a poll and ask at least 100 random respondents then you will have a good enough sample. People who read Ben's blog and who can afford to attend the conferences may not be most representative of all torque users, especially newbies.

But I am glad to learn that Ben is open to torquescript improvements.

#19 But I am sure that Ben is very much in touch with the Torque power users (I guess the indy studios who have games under their belt, or will be releasing something real soon). It's only natural that those power users get the features *they* want. If they didn't it, it wouldn't be equitable for them.

#20 Alex, since you seem to not be willing to take statements at face value and instead slide them around to either send a veiled barb, or change what the discussion is about (see your posts regarding TDN, and the differences between tutorial documentation and inline code documentation), I see no reason to continue this discussion on my part.

I would suggest that you keep in mind that since the forums are the means of support for your issues, you may want to reconsider your posting posture if you wish to gain assistance in the future. Note that others have posted in this thread, and your logo thread in a very polite manner even after the "hiccup" in the TDN thread, but you continue to argue about the responses when you don't hear what you want, instead of accepting other's opinions and attempts to help you.

Finally, I would like to add that everyone's participation in this (and other) forums is voluntary--from the newest member through the most experienced Associate, all the way to the employees. Many of us spend hours a day trying to help as many people as we can, but in cases like this we tend to stop responding.