Make assignment in if statements issue a warning
by Jason McIntosh · in Torque Game Builder · 06/30/2005 (2:47 pm) · 25 replies
For pete's sake, why is there no warning for something like this:
if ( i = 0 ) { ... }I just spent about 2 hours hunting a phantom bug thanks to this typo. Grrrr!!!
About the author
#22
07/20/2005 (3:55 pm)
NOTE: As A Torque owner you have full access to the source code. If you feel that ANY part of the engine needs to be changed to make YOUR workflow easier. YOU are quite free to make that change. You are also free to post the changes you made for others to view, download and use. If those changes gain wide acceptance by a large number of people, are easy to maintain, and do not break (within reason) any previous functionality, it will then be considered for inclusion into the the current HEAD / next release of TGE.
#23
Of course it is. In fact, you're doing it right now as you read this.
English, and most other human languages, is a context sensitive grammar. So you can indeed parse grammar that acts differently in context.
And you don't even need to have the grammar be context sensitive to do this. It's as simple as having your grammar look something like:
if ( COMPARISON_EXPRESSION )
as opposed to the C/C++ version:
if ( EXPRESSION )
Understanding this only requires not thinking of what goes on in an 'if' statement as a generic expression, but a particular kind of expression. This is probably not suitable for a low-level language like C/C++, but it makes perfect sense for higher-level languages like scripting languages. After all, such languages are designed to be more foolproof (to some degrees, at least) than low-level ones. And executing expressions that set variables in the middle of an 'if' statement is typically a confusing thing to do. More concise, sure; but certainly confusing.
The reason for the confusion, of course, is as follows: what is the result of the expression?
Offhand, I would guess B, but I would have to look it up to be sure. If I were writting the C/C++ language, and this question came up, there are good justifications for either choice. B makes sense if you want to use this operator in the middle of some other statement. However, A makes sense for the following ability:
It'd be great if this expression swapped the value of A and B. To do that, the result of the expression would have to be A, not B. The fact that there are cases for both of these means that anytime I use or see the equal operator as an expression (as opposed to a simple statement), I have to think about what the result of th expression is.
Oh, sure, I could memorize what the answer is ;) (or deduce it from what I know of code that does and doesn't work), but I would rather spend my time writing code rather than deducing what the results of ill-conceived operations are. There's a reason why many compilers have switches that turn warnings for these kinds of behaviors on; it's because they are, 99 times out of 100, bugs and not the intended wishes of the programmer. And the other 1 time, there's usually a more lucid way of expressing the code.
... I'm not sure what the purpose of this message is. This is the "Suggestions" forum, after all. It makes perfect sense for us to discuss suggestions here. The fact that, in theory, we could implement these suggestions ourselves does not make the suggestions themselves invalid, nor does it require that we prove our case via functioning, "easy to maintain" implementations. Indeed, the fact that there is a "Suggestions" forum at all seems to validate the concept that we can post and discuss suggestions to the GG crew as to changes that they might make to their engine.
Plus, your "full access to the source code" argument fails when talking to non-programmers. You can't expect an artist or any other non-coder who wants to make a game to be able to make anything of the T2D source code. And, even for coders, the lack of access to the appropriate portions of TGE's documentation makes this a less-than-trivial excercise.
07/20/2005 (4:57 pm)
Quote:The parser in my brain isn't optimized for things that act differently depending on context.
Of course it is. In fact, you're doing it right now as you read this.
English, and most other human languages, is a context sensitive grammar. So you can indeed parse grammar that acts differently in context.
And you don't even need to have the grammar be context sensitive to do this. It's as simple as having your grammar look something like:
if ( COMPARISON_EXPRESSION )
as opposed to the C/C++ version:
if ( EXPRESSION )
Understanding this only requires not thinking of what goes on in an 'if' statement as a generic expression, but a particular kind of expression. This is probably not suitable for a low-level language like C/C++, but it makes perfect sense for higher-level languages like scripting languages. After all, such languages are designed to be more foolproof (to some degrees, at least) than low-level ones. And executing expressions that set variables in the middle of an 'if' statement is typically a confusing thing to do. More concise, sure; but certainly confusing.
The reason for the confusion, of course, is as follows: what is the result of the expression?
A = B
Offhand, I would guess B, but I would have to look it up to be sure. If I were writting the C/C++ language, and this question came up, there are good justifications for either choice. B makes sense if you want to use this operator in the middle of some other statement. However, A makes sense for the following ability:
B = (A = B)
It'd be great if this expression swapped the value of A and B. To do that, the result of the expression would have to be A, not B. The fact that there are cases for both of these means that anytime I use or see the equal operator as an expression (as opposed to a simple statement), I have to think about what the result of th expression is.
Oh, sure, I could memorize what the answer is ;) (or deduce it from what I know of code that does and doesn't work), but I would rather spend my time writing code rather than deducing what the results of ill-conceived operations are. There's a reason why many compilers have switches that turn warnings for these kinds of behaviors on; it's because they are, 99 times out of 100, bugs and not the intended wishes of the programmer. And the other 1 time, there's usually a more lucid way of expressing the code.
Quote:As A Torque owner you have full access to the source code. If you feel that ANY part of the engine needs to be changed to make YOUR workflow easier. YOU are quite free to make that change. You are also free to post the changes you made for others to view, download and use. If those changes gain wide acceptance by a large number of people, are easy to maintain, and do not break (within reason) any previous functionality, it will then be considered for inclusion into the the current HEAD / next release of TGE.
... I'm not sure what the purpose of this message is. This is the "Suggestions" forum, after all. It makes perfect sense for us to discuss suggestions here. The fact that, in theory, we could implement these suggestions ourselves does not make the suggestions themselves invalid, nor does it require that we prove our case via functioning, "easy to maintain" implementations. Indeed, the fact that there is a "Suggestions" forum at all seems to validate the concept that we can post and discuss suggestions to the GG crew as to changes that they might make to their engine.
Plus, your "full access to the source code" argument fails when talking to non-programmers. You can't expect an artist or any other non-coder who wants to make a game to be able to make anything of the T2D source code. And, even for coders, the lack of access to the appropriate portions of TGE's documentation makes this a less-than-trivial excercise.
#24
07/20/2005 (6:03 pm)
If you weren't a programmer, you wouldn't care about this functionality. If you really wanted to change this you could go right into the console code and change it. Torque/T2D is C++ not voodoo magic. If you want to implement something in it, you just have to study the code, and add your changes. If you need access to the documentation you say you are lacking, its very easy to generate. Just run doxygen on the source code. You will get the same documentation that you get with TGE for the most part, minus the TGE specific bits.
#25
The Object Oriented extension for TorquScript for example
The Python Wrapper for Torque
Day / Night cycles
There were already over 20 posts in this thread with no consensus about how it should be and no one stepping forward to make the change. People expect the GG's guys to make all the changes to the engine they want.... that isn't how it works.
You will also note that this is the T2D suggestions forum, the behaviour in question is a CORE ENGINE change.... and would be better suited to be posted in the apporpriate forum.
07/20/2005 (8:35 pm)
Smaug - There is a difference between asking for current engine behaviour to be changed and suggesting new features. There is also a point when a suggestion becomes begging for a feature you don't want to code yourself. There are also features that although they might have been a suggestion do not have a use to the wide range of developers working with the engine.The Object Oriented extension for TorquScript for example
The Python Wrapper for Torque
Day / Night cycles
There were already over 20 posts in this thread with no consensus about how it should be and no one stepping forward to make the change. People expect the GG's guys to make all the changes to the engine they want.... that isn't how it works.
You will also note that this is the T2D suggestions forum, the behaviour in question is a CORE ENGINE change.... and would be better suited to be posted in the apporpriate forum.
Associate Ray Gebhardt