Boolean constants - Revision history

Sunjammer: Remove unnecessary whitespace

2020-04-13T17:30:46Z

Remove unnecessary whitespace

Sunjammer: Rewritten

2020-04-13T17:28:24Z

Rewritten

BryanDerksen: add in a bit about FALSE, as mentioned on talk. Feel free to edit this more, Axe Murderer, my previous trimming was merely an attempt to find a compromise position.

2009-10-28T17:53:59Z

add in a bit about FALSE, as mentioned on talk. Feel free to edit this more, Axe Murderer, my previous trimming was merely an attempt to find a compromise position.

Axe Murderer: added another example

2009-10-28T10:16:17Z

added another example

BryanDerksen: condensing AxeMurderer's contributions to hit the key points more strongly, and distributing to appropriate sections.

2009-10-26T15:47:07Z

condensing AxeMurderer's contributions to hit the key points more strongly, and distributing to appropriate sections.

Sunjammer: moved infromation not pertinent to constants to Discussion tab

2009-10-25T00:13:22Z

moved infromation not pertinent to constants to Discussion tab

Axe Murderer: grammar

2009-10-25T00:04:53Z

grammar

Axe Murderer: grammar

2009-10-25T00:03:19Z

grammar

Axe Murderer: grammar

2009-10-25T00:01:59Z

grammar

Axe Murderer: spelling

2009-10-24T23:54:44Z

spelling

← Older revision		Revision as of 17:30, 13 April 2020
Line 54:		Line 54:

	<dascript>		<dascript>
−	// make sure there is a location, just in case	+	// make sure there is a location, just in case
−	if(IsObjectValid(stEvent.oTarget) == TRUE)	+	if(IsObjectValid(stEvent.oTarget) == TRUE)
−	{	+	{
−	stEvent.lTarget = GetLocation(stEvent.oTarget);	+	stEvent.lTarget = GetLocation(stEvent.oTarget);
−	}	+	}
	</dascript>		</dascript>

Line 64:		Line 64:

	<dascript>		<dascript>
−	// make sure there is a location, just in case	+	// make sure there is a location, just in case
−	if(IsObjectValid(stEvent.oTarget))	+	if(IsObjectValid(stEvent.oTarget))
−	{	+	{
−	stEvent.lTarget = GetLocation(stEvent.oTarget);	+	stEvent.lTarget = GetLocation(stEvent.oTarget);
−	}	+	}
	</dascript>		</dascript>

Line 97:		Line 97:

	<dascript>		<dascript>
−	// Replace this:	+	// Replace this:
−	if(IsObjectValid(oTarget) == FALSE)	+	if(IsObjectValid(oTarget) == FALSE)
−	{	+	{
−	...	+	...
−	}	+	}

−		+	// With this:
−	// With this:	+	if(!IsObjectValid(oTarget))
−	if(!IsObjectValid(oTarget))	+	{
−	{	+	...
−	...	+	}
−	}	+
	</dascript>		</dascript>

@@ Line 23: / Line 23: @@
 == Remarks ==
 <!-- This section contains additional comments, observations and known issues. -->
-Note that the DA scripting language does not have an explicit boolean type, and using [[integer]]s to simulate it in this manner can lead to potentially subtle ambiguity.
+These constants are used in the following ways in '''script.ldf''', the [[Core Game Resources]] and the [[Single Player Campaign]]:
-If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1)
+// Setting the a value of an integer argument in a function call.
-== Examples ==
+// Setting the default value of an integer argument in a function's declaration or definition.
-<!-- This section contains examples transcluded from the snippet library. -->
+void AddAbility(object oObject, int nAbility, int bSendNotification = FALSE);
-Note also that it is never necessary, and furthermore wasteful, to explicitly "test for TRUE" or "test for NOT FALSE" in a boolean expression anyway. One would never write, for example:
-<pre>
-if( (x == y) == TRUE ) ...  <-- redundant comparison with TRUE
-if( (x == y) != FALSE ) ...  <-- redundant comparison with FALSE
-</pre>
-because the sub-expression (x == y) will evaluate to TRUE or FALSE already. One should instead write:
-<pre>
-if (x == y) ...
-if ( !(x == y) ) ...
-</pre>
-If you follow this pattern the ambiguity described in "Remarks" above will never impact your code's behaviour.
+// Setting a return value from an integer function.
-The identifiers TRUE and FALSE are only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, returning a boolean result from a function, or setting the value of a boolean type variable. There is no other place where you need it.
+The constants are also referenced in the comments describing a function's return values, for example, as seen is [[IsObjectValid]], to indicate that the function is constrained to return 0 or 1. This is probably reliable for engine functions (i.e. those in '''script.ldf''') which are presumably converting from a native C++ '''bool''' type but should be treated with scepticism for scripted functions.
-<pre>
-void Dance( int bChaCha = TRUE)... <-- default value in function def
-SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
-return TRUE; <-- return value from a function
-int bStillLooking = TRUE; <-- set a variable value
-</pre>
-Note that since the FALSE constant is not ambiguous (only the value 0 ever means "false") you ''can'' test for it without potential side effects. For example:
+Finally the constants are also used in boolean expressions, for example, in an '''if''' statement:
-<pre>
+<dascript>
-if( IsObjectValid( oObject) == FALSE)
+if(<expression> == TRUE)
-</pre>
 == See also ==
 <!-- This section contains links to articles, functions or constant groups. -->
-*See [[bool (2da type)]] for booleans used in [[2DA]]s.
+*[[bool (2da type)]] for boolean values in [[2DA]]s
 [[Category:Constants]]

@@ Line 51: / Line 51: @@
 </pre>
 == See also ==
 <!-- This section contains links to articles, functions or constant groups. -->

@@ Line 43: / Line 43: @@
 If you follow this pattern the ambiguity described in "Remarks" above will never impact your code's behaviour.
-The identifiers TRUE and FALSE are only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, or setting the value of a boolean type variable. There is no other place where you need it.
+The identifiers TRUE and FALSE are only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, returning a boolean result from a function, or setting the value of a boolean type variable. There is no other place where you need it.
 <pre>
 void Dance( int bChaCha = TRUE)... <-- default value in function def
 SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
 int bStillLooking = TRUE; <-- set a variable value
 </pre>

@@ Line 1: / Line 1: @@
 {{Constant table start
 |sourcefile=script.ldf
@@ Line 22: / Line 21: @@
 {{Constant table end}}
-<!--== Remarks == -->
+== Remarks ==
 <!-- This section contains additional comments, observations and known issues. -->
-<!-- == Examples == -->
+If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1)
 <!-- This section contains examples transcluded from the snippet library. -->
-<!-- == See also == -->
+== See also ==
 <!-- This section contains links to articles, functions or constant groups. -->
 [[Category:Constants]]

@@ Line 42: / Line 42: @@
 The same logic applies to expressions involving function calls. If a function returns a TRUE/FALSE value, it would be a redundant waste of CPU cycles to test if the returned value was TRUE.
 <pre>
-if( IsObjectValid( oObject) == TRUE) ... <-- this is redundant as well
+if( IsObjectValid( oObject) != FALSE) ... <-- this is redundant as well
-if( IsObjectValid( oObject) != FALSE) ... <-- as is this
+if( IsObjectValid( oObject) == TRUE) ... <-- as is this, also it's ambiguous
 if( IsObjectValid( oObject) ) ... <-- same thing, one less comparison
 </pre>

@@ Line 51: / Line 51: @@
 <pre>
 if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant
-if( IsObjectValid( oObject) != TRUE) ... <-- this is not redundant either
+if( IsObjectValid( oObject) != TRUE) ... <-- not redundant either but is ambiguous
 if( !IsObjectValid( oObject) ) ... <-- but this might be the best method
 </pre>

@@ Line 48: / Line 48: @@
 In this case the return value of the function (TRUE/FALSE) has the same logic characteristics as the sub-expression (x == y) in the example above. So you can treat the function call as a boolean sub-expression just like (x == y) and therefore the same logic leads to the same conclusion concerning the overall expression.
-However, testing for FALSE or NOT TRUE is perfectly acceptable:
+In contrast, testing for FALSE or for NOT TRUE is perfectly acceptable:
 <pre>
 if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant

@@ Line 62: / Line 62: @@
 </pre>
-Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read experessions without it having to be there would benefit anybody.
+Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read expressions without it having to be there would benefit anybody.
 <!-- == Examples == -->