Make assignment in if statements issue a warning

#1 I've done the same thing several times before, so, yeah. For my sake, why is ther no warning?

-Peter

#2 Well guys, if you're talking about in script then the answer is because there are no warnings in script compilation, and if you're talking about in code and you're using Visual Studio, set your compiler warning level to 4 and it should let you know :)

-justin'

#3 I was talking about TorqueScript. Seems this oversight could be remedied since GG has control of what the script compiler does. :) I dunno, it's just frustrating to me using TS as the basis of a full scale game. Had to vent a little.

#4 Well you could use the old work around of doing something like

if(0 == %i) { ... }

If you make it a habit, its a less likely that you will have that issue. On the other hand I don't use that technique, and I never have an issue with accidental assignment. It must be my machine like mind or something.

#5 Couldn't torque just mention it in the console in red? When I change things and it doesn't work the first thing I do is check the console.

-Peter

I'm stuck with this human brain.

#6 I'm with Peter. We have human brains (not to dis those of you with machine-like minds, but...), and machines--especially compilers--are meant to be tools which should help reduce bugs. I'm just whining, though.

Soon I'll have my sweet Python and this won't be an issue. :)

#7 I always try and get my programmers to use the

if(0 == var)

method at all times (in C++ or TS or PHP or anything else). It enforces safety, and once you are used to it you know at a glance it's a static comparison.

Of course, warnings on assignments would still be nice, since a var = var can't be reversed to enforce safety.

#8 The only problem is, code that already depends on var = var kind of assignment during comparison will throw warnings. It woud "break" existing code in the sense that code that used to be perfectly good, will start to throw warnings. Assignment during comparison is a completely legal operation, and since Torque Script is a scripting langauge, the warning probably would be more annoying than helpful. In a compiler, warnings are nice, because they tell you that you have code that might be incorrect before you run the application. Now what you could do, is write a few scripts that check your code for errors that you commonly make, and run those scripts before you test them in T2D. This is what a lot of developer of the Linux kernel do, and its a very helpful way to catch errors that are commonly made by your team.

#9 Ohhh... I think this may have something to do with a problem I was having last night...
mind you I did try == and still had some problem with what I was trying to do, but that's just me making mistakes :)

No actually not.. I must have been blind when I saw this post...
sorry.

#10 @Ray: Using assignment in a comparison statement should not be legal syntax. It's confusing and makes the code hard to read. It doesn't provide any benefits other than saving some typing time. So IMHO that shouldn't be a design consideration.

Just saying. :)

#11 Well that's person preference. I never do assignment during comparison. The problem is that C, C++, C# and most other C like languages let you do assignment during comparison. If you made assignment in a comparison illegal, it would make the language more confusing, because it would be like C, but with arbitrary exceptions. It would break existing code that is already in existing games. It would be like changing the C standard to not consider assignment in a comparison as a legal statement. Thousands of programs would instantly break when they are recompiled. So i think the best idea is to write your own scripts to test your code for common errors, than to change a the language specification.

#12 If you create a script language you're hardly bound to some other languages standards. Using some syntax from C is not the same as using its semantics. And it's already like C with arbitrary changes. I don't think that obscure "feature" is going to confuse TorqueScript programmers, but it would make the language less error prone and more readable.

Having said that, I agree that this is a fundamental design decision, and it would make more sense to not change it now.

#13 [quote]If you create a script language you're hardly bound to some other languages standards.[quote]

While I agree in principle, we already have lots of TScript code out there. While I would hope that most TScripters aren't willing to use a misfeature like this, plenty of TScripters are/used to be coders, so I would imagine that a fair bit of TScript includes this unfortunate construct.

However, if it ever comes to pass that they will make some non-backwards compatible change to TScript, then I'm all for dropping this misfeature at the same time. If you're going to break the world to rebuild it, it's best to rebuild it correctly.

#14 I always thought C was built correctly. If it wasn't, we wouldn't be running any of the operating systems we are running right now. C++ is also based off of C, which means we wouldn't be running torque. I don't really think that means its broken. C is a compiled language, and it makes sense to have a warning. Scripting languages are usually extremely lenient, and allow uses to do potentially nasty operations, like completely dynamic types. I have a strong personal preference of keeping C like languages like C, with as few arbitrary exceptions as possible. If TorqueScript was a completely new, from scratch language it would make sense. The only times TorqueScript really deviates from C is when it adds more object oriented features, allows completely dynamic typing, and the $= type operators to optimize string operations. There are no arbitrary deviations for C in TorqueScript. If you look at C#, it's a from scratch refactoring of C++, and it still allows for assignment on comparison.

#15 Let's not get into a C/C++ flamewar. I really don't like C/C++ much at all, I'll just say that. :)

Because C is used in so many places is not evidence it is correct. (Correctness is a subjective term anyway.) I must also disagree that TS isn't arbitrarily different from C. TS is weakly dynamically typed. C is strongly statically typed. That single change disallows calling them the same language anymore, not to mention the namespace rules of TS and the flavor of OO TS uses which completely deviates from C++. It's definitely not C/C++ in any strict sense other than syntactically.

One reason I was attracted to T2D is that there's no C++ twiddling except in rare cases. I don't want to write low-level subsystems. I want to write game logic!

We must acknowledge that C vs TorqueScript are two very different tools for different kinds of problems. So comparing them isn't really useful except for the fact that TS models its syntax after C. And my point wasn't to compare them at all, really, just that I personally wish a lot of things were different in TorqueScript because they don't seem correct considering it's purpose.

Ergo, performing an assignment in a comparison statement should be blatantly incorrect. The purpose of the statement is to compare, not to assign. *shrugs* It just muddles the semantics of the language in favor of a syntactic shortcut. That's not a compelling reason to include it when weighed against the potential for bugs and confusion it causes.

#16 Well the problem is, that the comparision is an expression. Arbitrary exceptions in a language are bad in my opinion. Anywhere that you can have an expression, I believe they should be allowed. For example:

$val1 = 1;
$val2 = 2;
echo($val1 > $val2);

The code above will return "0". If you then type the following you get "1".

echo($val1 < $val2);

If you keep things consistant, it makes a language much easier to understand, and easier for the parser to execute. You won't have to think "hmmm...I can do this operation in this case, but not in this other case".

Now when it comes to scripting languages, I am not in love with TorqueScript. I wouldn't want to change it though, unless it was a drastic change. Implementing a new TorqueScript language using something like Ruby would be amazing. I have always thought C style scripting languages are a bad idea, since C is the complete opposite of a scripting language. For example having semi colons at the end of every line in script is kind of a waste. It just means that much more typing for a language designed to rapid development. Languages like Ruby and Python have a terse syntax that allows you to get a lot done, with very little code. Yet at the same time the code is easier to understand than C code, generally speaking.

#17 Well, I'm in love with Python (that's no secret, probably). Edo and I are going to bring it to T2D soon, based upon the previous work done by Tomas Dahle et al. So this TorqueScript nonsense will be a thing of the past. :)

#18 Actually added Python as a scripting language for Torque wouldn't be the hard part. The hard part would be converting all the basic scripts over to the syntax of Python. That would be a real pain. Of course you could just rewrite them from scratch.

#19 I haven't dug too deep yet (finishing another project first), but Tomas has already gotten it working without writing wrappers for every function. All it really needs is sound support and some fixes to the scheduling functionality.

Hopefully within the next few weeks we'll have something on offer, as Edo and I both plan to use Python for our next games.

#20

Quote:Well the problem is, that the comparision is an expression.

That's a way to see things. However, it isn't the only way.

Comparison is a type of expression. Once you subdivide expressions into classifications (comparisons, values, set variable, etc), rules based on different types of expressions are no longer arbitrary. It makes sense that expressions that set variables are fundamentally different from expressions that compare two values, or from expressions that evaluate to a value (or a non-bool value).

Putting all kinds of expressions under the single rubric "expression" is a parser optimization; nothing more. It doesn't have to be that way, and it was probably done back in the days when the parsing phase of compilation was a significant performance bottleneck. Nowadays, it most certainly isn't.