I noticed that in the DM Reference, apparently all entries (except for the one on null) regard false values as equal to 0, or more commonly, regard true values as "non-zero"; CTRL-F for this "true (non-zero)" in the DM Reference. Basically all entries that have this or similar, are misleading and should be fixed. This may be a big factor in the "== operator abusage" in checking for 0/1 values.
Most importantly, this is also wrong in the entries for things like the if statement and the ! operator.
I'm not sure if this was left unupdated or not or is there for some other reason, but the reference should be more accurate for the sake of DM-newbies that don't know what true/false values in DM are.
ID:133534
 Jun 30 2008, 4:52 pm
|
|
|
Jun 30 2008, 10:46 pm
|
|
Jp
 |
For people who're wondering why this is wrong, null and "" are nonzero and false.
|
Indeed. Like I said, this is touched upon correctly here.
| |
I thought all the people new to DM code were reading some newb guide somewhere, because they all seem to make the same mistake of checking var==0 and var==1 when evaluating boolean variables.
| |
Jp wrote:
For people who're wondering why this is wrong, null and "" are nonzero and false. So what exactly do you people want it so say? "true (not nothing)"? That would be even more confusing, its pretty much common sense that null 0 "" and anything else that lacks existant would qualify as a zero value EDIT: And as far as boolean variables go, they dont truely exist in DM | |
Besides opacity and density, and maybe something else that's built-in I'm forgetting.
And, it's how you use your code that defines it as boolean or not, not some weird magical outside force that makes it a "true boolean." | |
Naokohiro wrote:
Besides opacity and density, and maybe something else that's built-in I'm forgetting. Huh? And, it's how you use your code that defines it as boolean or not, not some weird magical outside force that makes it a "true boolean." In strongly typed programming languages like C++ and VB you declare your variables as boolean when you want them to be boolean. If anything byond is the one with the "weird magical outside force" that magicaly makes all its variable types function like one another | |
While I can see where you're coming from here, would you propose changing true (non-zero) to true (not equal to null, 0, or "") everywhere it appears? That seems unwieldy to me.
I doubt these people are picking up the "==1" habit from the reference; that's probably their own mathematical intuition (correct or not) asserting itself. =) | |
Falacy wrote:
Naokohiro wrote: I think you don't know what boolean is. On atoms in DM, density and opacity are always boolean no matter what. They are meant to only be set to 1 or 0; a true or false situation. And, it's how you use your code that defines it as boolean or not, not some weird magical outside force that makes it a "true boolean." This isn't C++ or VB, this is BYOND. >_> In BYOND, they made everything a little better by making false be either 0, null or "" and then true being anything that isn't those three. Instead of just 1 being true and 0 being false. The BYOND usage simplifies if statements in an object-oriented design. (Or even text-based design.) | |
Falacy wrote:
In strongly typed programming languages like C++ and VB you declare your variables as boolean [...] That means squat. DM is simply a convenient non-strongly-typed language, but that doesn't mean it doesn't have integers, booleans, strings, or other data types. It does. The only added benefit you'd have by declaring variables as boolean is making them more dumbproof, for the cost of being less flexible as well as unjustly inconvenient for non-dumb programmers. | |
Jtgibson wrote:
While I can see where you're coming from here, would you propose changing true (non-zero) to true (not equal to null, 0, or "") everywhere it appears? Indeed, as you've noticed, I was reporting a problem, and not suggesting a possible solution (since it's the BYOND Staff's to decide at any case, I left it for them). =P True, that would be unwieldy - if I were to choose the solution, I'd suggest simply making new Reference entries for 'true values' and 'false values'. Seeing as we already have entries for the more "arbitrary" (I mean, non proc/statement/var/operator) things like 'null' and 'garbage collection', it would not be out of the norm. Those entries would be linked (as See also) in the needed entries (if, !, while...), and those entries would instead only say "true value" or "false value", no unwieldy expanding. You could then have more detail than ever in those entries (that should also link to each-other and to if()), explaining what false values are, explaining that commonly in programming 1 is used to denote a positive value (as, "on", or "yes", or "success") and 0 as a negative value ("off"/"no"/"failure), but that true values are in actuality anything other than false values and false values can be 3 different values. Then it'd go further to explain the TRUE and FALSE built-in macros (which sometimes also bring up confusion) that they're just (so-called) macro shortcuts for 1 and 0, and not some magic positive/negative indicator values. OF COURSE, all the above in a much more easy to understand and detailedly than me here. =P Also, making separate entries for those would also benefit in the case they were updated again (I'm assuming in the old old days before I even knew of the site, false values may have truly only been 0 and later updated, which may be the cause for this), and they could add more values as needed in a central place rather than hunting them down throughout the Reference (which they kinda have to do now... but we can help with that if needed). I doubt these people are picking up the "==1" habit from the reference; Same, almost most of those are the kind of people that don't read the Reference. However, the rest, who do, can be confused by it, as it is currently. Besides, a Reference should be correct and accurate by definition, of course. | |