Interesting facts about TorqueScript
by Jason McIntosh · in Torque Game Builder · 03/08/2005 (8:07 pm) · 26 replies
Through some confusing trial and error (and contrary to the TorqueScript docs), switch statements do not need break statements after each case like C++ does.
Maybe knowing this will save you time when you come across this curious circumstance.
(Apart from these types of quirks, I'm really enjoying TorqueScript.)
switch ( expression )
{
case 1: statement;
case 2: statement;
case 3: statement;
case n: statement;
}I have a switch statement inside a for loop, and the break was causing the for loop to stop. I would expect that from a break statement if it wasn't in a switch() statement. :)Maybe knowing this will save you time when you come across this curious circumstance.
(Apart from these types of quirks, I'm really enjoying TorqueScript.)
About the author
#22
03/10/2005 (5:42 am)
That would be good, althought I'd like to point out TorqueScript does have arrays and C does not have hash maps (C++'s STL is another story).
#23
Anyway, I agree that a language war is definitely unnecessary. Whenever you create a new language, one hopes you do it for a good reason. TorqueScript was written for gaming and specifically for TGE. In that regard I am sure it is very good at what it needs to do.
On the other hand, like many others, I have gone from shock to pure amazement while looking at the constructs in this language. Some are just blatantly Bad (ie. the array one I mentioned above) while others are just puzzling (ie. "inlining" constructors). I too had considered the possibility of integrating another scripting language but thought better of it. In the end, it's way too much effort for too little benefit.
Like Gary mentioned above, the best defense against the ills of TorqueScript is to avoid using the unusual "syntactic sugars" whenever possible.
03/10/2005 (6:17 am)
Wow, who woulda thunk this thread would explode?Anyway, I agree that a language war is definitely unnecessary. Whenever you create a new language, one hopes you do it for a good reason. TorqueScript was written for gaming and specifically for TGE. In that regard I am sure it is very good at what it needs to do.
On the other hand, like many others, I have gone from shock to pure amazement while looking at the constructs in this language. Some are just blatantly Bad (ie. the array one I mentioned above) while others are just puzzling (ie. "inlining" constructors). I too had considered the possibility of integrating another scripting language but thought better of it. In the end, it's way too much effort for too little benefit.
Like Gary mentioned above, the best defense against the ills of TorqueScript is to avoid using the unusual "syntactic sugars" whenever possible.
#24
As a language for doing what torquescript is designed for, I find it to be GREAT.
Overall, I feel that people who say "torque doen't have arrays and that's bad" are actually wrong; it has arrays from the torquescript programmer's perspective, that it does something interesting wth internally. This isn't a bad thing, it's just a facet of writing a language where you want it to be fast.
Pick a good policy of variable naming, you never need to know that there aren't arrays; No variables whose name is another variables's name with an appended digit would be about all you need. If you're using it for hashes, then no variables whose name is another variable's name with stuff appended to it, where "stuff" is anything you might want to hash.
This is a SCRIPTING language, kids. The odd wart like this is part of the experience. I could go on for hours about the things I don't like in most of the languages that I know or use day-to-day.
The switch/case break thing is really annoying to me, but it's nothing too unreasonable in terms of language design, all things considered. The ++ and -- operators... well, just file it away mentally.
I'm with the torquescript kool-aid program, in case it's not obvious. There are some bits of it that I dislike, but that's pretty much the case with any language.
This discussion's good, too.Thanks Melv for the ref, I couldn't find it in the forums anywhere :-)
Gary (-;
03/10/2005 (10:42 am)
OK, all the bashing aside, I'd just like to say;As a language for doing what torquescript is designed for, I find it to be GREAT.
Overall, I feel that people who say "torque doen't have arrays and that's bad" are actually wrong; it has arrays from the torquescript programmer's perspective, that it does something interesting wth internally. This isn't a bad thing, it's just a facet of writing a language where you want it to be fast.
Pick a good policy of variable naming, you never need to know that there aren't arrays; No variables whose name is another variables's name with an appended digit would be about all you need. If you're using it for hashes, then no variables whose name is another variable's name with stuff appended to it, where "stuff" is anything you might want to hash.
This is a SCRIPTING language, kids. The odd wart like this is part of the experience. I could go on for hours about the things I don't like in most of the languages that I know or use day-to-day.
The switch/case break thing is really annoying to me, but it's nothing too unreasonable in terms of language design, all things considered. The ++ and -- operators... well, just file it away mentally.
I'm with the torquescript kool-aid program, in case it's not obvious. There are some bits of it that I dislike, but that's pretty much the case with any language.
This discussion's good, too.Thanks Melv for the ref, I couldn't find it in the forums anywhere :-)
Gary (-;
#25
Guys, if you need something implemented differently, or implemented in the first place for your project--implement it! You have the source code.
Discussion of array implementation has been around since the 70's. You can find implementations for hash maps all over the internet, as well as in dozens of textbooks on abstract data types.
To give an example of how this type of thing is not limited to TGEScript at all: TCL is a scripting language I've been using for almost 10 years now. It does some great stuff, but if you look at some of the underlying implementations, it's atrocious. As an example, TCL is heavily based around the concept of "lists", which is an ordered set of string tokens. You'd think that it would be represented internally as a highly efficient, optimized for access/search dataset, but they use good old singly linked lists....and if you now much about search performance, that is a terrible implementation for extremely large lists.
The thing is, for those that need massively large lists, they have the source code--just change the implementation. For a good 80% of the TCL users, a singly linked list works fine.
Like Gary said, this is a SCRIPTING language, and a very large portion of scripting languages are going to elect to implement things in ways that are useful for most of the user base (or not even implement them at all). TGEScript is no different in that respect!
03/10/2005 (11:09 am)
Quote:Is there a document like "Torque Script for C coders"?
I must admit that I'm kinda shocked after reading this thread... no arrays? No hash maps? Operators and conditionals working differently?
My eyes got wider and wider while reading the posts... If there are more of these gotchas, I'd love to see them collected somewhere.
Guys, if you need something implemented differently, or implemented in the first place for your project--implement it! You have the source code.
Discussion of array implementation has been around since the 70's. You can find implementations for hash maps all over the internet, as well as in dozens of textbooks on abstract data types.
To give an example of how this type of thing is not limited to TGEScript at all: TCL is a scripting language I've been using for almost 10 years now. It does some great stuff, but if you look at some of the underlying implementations, it's atrocious. As an example, TCL is heavily based around the concept of "lists", which is an ordered set of string tokens. You'd think that it would be represented internally as a highly efficient, optimized for access/search dataset, but they use good old singly linked lists....and if you now much about search performance, that is a terrible implementation for extremely large lists.
The thing is, for those that need massively large lists, they have the source code--just change the implementation. For a good 80% of the TCL users, a singly linked list works fine.
Like Gary said, this is a SCRIPTING language, and a very large portion of scripting languages are going to elect to implement things in ways that are useful for most of the user base (or not even implement them at all). TGEScript is no different in that respect!
#26
The switch/case/break thing is not so bad once you get used to it or you need cases to fall through, but that's not too common, so I can deal with it. Not having to make sure my breaks match up to my cases (thereby avoiding accidental fall throughs) is actually kind of nice.
Now I just need more time to practice with the OO additions made by Brian. :)
03/10/2005 (1:41 pm)
The array implementation is clever from an optimization point of view, and seems adequate for now. I guess it just requires getting used to.The switch/case/break thing is not so bad once you get used to it or you need cases to fall through, but that's not too common, so I can deal with it. Not having to make sure my breaks match up to my cases (thereby avoiding accidental fall throughs) is actually kind of nice.
Now I just need more time to practice with the OO additions made by Brian. :)
Torque Owner Lennart Steinke
I must admit that I'm kinda shocked after reading this thread... no arrays? No hash maps? Operators and conditionals working differently?
My eyes got wider and wider while reading the posts... If there are more of these gotchas, I'd love to see them collected somewhere.