In response to Kaioken
Kaioken wrote:
Perhaps because it is entirely unrequired, and adding it only introduces slight loss of robustness and efficiency. Heard of boolean checking?

No it doesn't. Why are you arguing irrelevant things? The only more robust solution than that would be istype(ref) to make sure you're actually dealing with the correct reference type. But this is fine, really. In any case, its not worth bringing up.
In response to Alathon
Alathon wrote:
No it doesn't.

It does. Since you didn't say more, I won't either.

Why are you arguing irrelevant things?

I simply mentioned it briefly, but he decided to make a sting out of it. He then asked a question, "why", so I kindly answered. Pretty straightforward, really.

As for your solution, I wasn't talking about the best solution. I was simply pointing out and questioning the typing of extra code to produce slightly worse results, as boolean checking suffices.
In response to Kaioken
It is exactly as robust. If I assign equipped_weapon to 5, then my if statement will incorrectly fire off as true, exactly the same as this if statement:

mob
var/obj/weapon/equipped_weapon

proc/run()
if (src.equipped_weapon) // Have a weapon
do_weapon_running_stuff()
else
default_running_thingy()


5 evaluates to true, regardless. If I throw the wrong type into equipped_weapon through some means, both statements still fail. I cannot find a case where "boolean checking" as you described it is any more robust than the != check, because it's the same logic. As for efficiency, I'm sure the VM will live by having to do a constant time reference existence check. I thought the efficiency talk in the goto thread was petty, this is just unbelievable.

Here's another lovely revelation, both statements are boolean. If they weren't boolean, it plain would not work, the very semantics of the if statement requires a boolean expression. If you're going to call it anything, call it reference checking. Even then, my statement is a reference check, just like the example above.

Here is the crux of the difference you are disputing. I am explicitly stating what you would've got the compiler to state. Why do I do this? Simple. Consider the point of a new programmer, then read these two statements:

// If the source's equipped weapon is not equal to null.
if (src.equipped_weapon != null)

// If the source's equipped weapon.
if (src.equipped_weapon)


The logic isn't great in the first one, you'd prefer to have a magic exists() proc in DM for syntactic sugar. However with a little thinking you can work out that if the weapon is not null (null as in blank, empty, does not exist), then it must surely exist. Leaving you with "Oh, so if the source's equipped weapon exists! Right". The second one however doesn't read great at all. If the source's equipped weapon ... what? Is a fish? For you, me and probably the OP too, this kind of implicit expression is second-nature to read. For a new programmer, I don't believe this would be so. In time they will learn these implicit compiler-assistive tricks, however I'm not going to assume that knowledge for a 'best practice' that no-one bothers explaining. It's not the end of the world either way, so I don't understand why you'd pick up on it.

I'm generally with Alathon, this has been a terrible waste of our collective time, it ends here. If you want to continue it, page me. Please don't split hairs like this again. Thanks.
Page: 1 2