• (nodebb)

    The story seems to confuse "brilliant" with "brillant", which is not a frist.

  • no (unregistered)

    But this solution also conceals another problem: a boolean variable which is true may be any nonzero value- which would break when we try and index the array by that.

    I wanna bet that's how that @ ended up there.

  • (nodebb) in reply to nerd4sale

    This is not unexpected. brillant would be true, while brilliant is false, of course.

  • (nodebb)

    Yes, PHP was truly awful when it was new, but who writes in PHP without using an IDE today? Programming without an IDE and static code validation in 2024 would be the WTF.

  • TheCPUWizard (unregistered)

    TrueFalse is natural, same as TickTock... the language puts an order to things, even when logic alone does not.

  • (nodebb)

    Languages which do type-coercion are generally setting users up for failure

    Most languages do at least some automatic type coercion (examples: pass an int to a function expecting signed long long int in C/C++, assign a non-bool value to a bool variable in C99+/C++(1), pass an integer to a function expecting a real in Pascal, ...), so you need an extra word in your sentence. I suggest "aggressive":

    Languages which do aggressive type-coercion are generally setting users up for failure

    And then I'll agree without hesitation.

    (1) That specific example's primary "sets up users for failure" problem operates in reverse, in fact, because it may lead you to assign that int or double or whatever to what turns out to be a non-bool variable, and get bitten by the fact that non-false values aren't all squashed together as true or at least 1. (The worst is narrowing conversions, e.g. a wider-than-char unsigned value assigned to an unsigned char, where you assign UCHAR_MAX+1 and you get a falseish value as the non-zero bit falls in the bit bucket, and the result is zero.)

    Lesson: If the variable (or function parameter) expects a true/false value (or even a false/true value), make it bool or boolean (depending on your language of choice). Always. Unless you're on C89/90, in which case wash the fluff out of your head and set your compiler to C99 or later.

  • (author) in reply to Steve_The_Cynic

    I was going to reply and be pedantic, but it turns out in common usage "type coercion" is used for any casting. I was going to argue that when a cast goes to a type that is a strict superset of the input and for which all the same operations are defined, that's just a "cast" and not a "coercion", but apparently that's not how other people talk.

  • (nodebb) in reply to Remy Porter

    I think the phrase you're looking for is "type juggling".

    They could have easily solved the "any non-zero value is true" problem with $trueFalse[boolval($some->integer->property)].

  • (nodebb) in reply to Remy Porter

    It's also a reasonable use of the word "coercion". The value is just there hanging out, happy as Larry, and suddenly the compiler (or the programmer in the case of explicit casts) comes along and says, "Nah, mate, you're going to be this other type now," without asking or even offering a choice. Sounds like coercion to me.

  • I must be doing it wrong then (unregistered)

    $some->integer->property would "suggest" that, at least, a whole number between 0 and PHP_INT_MAX was expected to be used (there could be the use of intval(x) behind that which would return 0 for anything other than a short list of "looks like a number" STRINGS.

    The "@" is probably there as an attempt to suppress the inevitable error when trying to access any array element above 1.

    An issue with PHP (and, probably, other languages) is anything submitted by a HTML Form is going to be a STRING so 0 is "0" and 1 is "1" (when such is used as an "index" the type coercion moaned about happens in the background). A similar issue is: TRUE is "true" and FALSE is "false".

    Somewhere else where this issue crops up is when to pulling back data using a MySQL / MySQLi "associated array" (the amount of time I have spend debugging because I'm testing for "x === 1"... - yes I could use x == 1 but then ..."nose demons").

    The above not withstanding, my solution to something like this would be:

    $useValue = 0;      // whatever state is the default / safest etc
if (intval($inputValue)) !== 0) { $useValue = 1; }
$boolStr = trueFalse[$useValue];
  • (nodebb) in reply to Remy Porter

    I was going to argue that when a cast goes to a type that is a strict superset of the input

    People talk about casts when the destination type is not a strict superset of the input e.g. C programmers would call

    int a = -1;
unsigned int b = a;

    a cast, or at least, an attempted one: it might be undefined behaviour, but I can't be bothered to look it up.

  • Duke of New York (unregistered)

    When a programming language obligates you to do something silly to get a result you can't really be faulted for doing it. As the Intercal manual observes, not doing it will only reflect back on you for putting your scruples above results.

    Also it's "trueFalse" instead of "falseTrue" under the influence of Indo-European vowel progression.

  • John (unregistered)

    I blame the legacy of C for pretending to use zero and one as boolean values.

  • LZ79LRU (unregistered) in reply to Duke of New York

    It should be a function called BoolToString().

  • (nodebb) in reply to Steve_The_Cynic

    And just one more headache for localization...having to support those regions where a value cannot be referred to by other than the type assigned at birth.

  • (nodebb) in reply to Duke of New York

    Also it's "trueFalse" instead of "falseTrue" under the influence of Indo-European vowel progression.

    Intriguing! Say more?

  • Duke of New York (unregistered) in reply to jkshapiro

    No

  • (nodebb) in reply to I must be doing it wrong then

    ...and as well as the (suppressed) warning, you get a FILE_NOT_FOUND, I mean NULL, as the result of the lookup instead of either string.

    Really, using booleans as keys isn't the problem, nor is having a boolean->string mapping so that you can have false represented by "no" and true represented by "yes". (PHP doesn't use booleans for array keys—they're coerced to integers—but [false => "off", true => "on"] is at least better at self-documentation.)

  • Offf (unregistered)

    I am shocked. How could they miss FILENOTFOUND??! CAPTCHA: Select all images that match the label: undefined.

Leave a comment on “False True is True False”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article