• LCrawford (unregistered)

    Of course, rsEmplExp.MoveFrist only applies when not True!

  • (nodebb)

    Or, and I think more likely, did someone get burned by type coercion once in the past

    The docs make me thing this is the case - it's a read-only Boolean. https://docs.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/recordset-eof-property-dao

  • Prime Mover (unregistered)

    Well indeed. Not all models of reality adhere to Tertium Non Datur.

    There is an entire branch of mathematics whose thesis is that TND may not necessarily hold.

    The programmer in this case is prudent and sensible, and has written code that is bullet-proof.

  • Industrial Automation Engineer (unregistered)

    I recognise the pattern. In my case the reason was "standards" (why use two constants when one suffices?) the other (anti-) patterns was to write it like if (true == someCondition) because one developer was once burned by: if (someCondition = true), however this application was written in VBA (yeah, you can poke fun now.)

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Visual Basic, you say? I remember from my kidhood that boolean expressions in MS-BASIC return 0 for false and -1 for true, but IF accepts any non-zero value as true. You just don't want to combine random "boolean" values with AND and OR because there's no && or || like operator. This looks like a cargo cult response by someone who discovered that the hard way.

  • Dave (unregistered)

    It's VBA. This is just a know-nothing version of 'if false or error'. It likely indicates something is mildly broken elsewhere in the code, but I don't think there's much to laugh about when beginners hack away until they get something working.

  • (nodebb) in reply to Steve_The_Cynic

    Reading that M$ doc, I come to the thought that some steps in the development of the code are nowadays missing: tinkering around with both BOF and EOF and their various combinations. And what ever crap they did with the recordset before they arrived at that line of code...

  • Rob (unregistered) in reply to Industrial Automation Engineer

    Which is why you should just omit the "= true" part: if (someCondition).

  • pif (unregistered)

    A sane compiler does not allow a boolean constant as an operand of a comparison operator.

    Unfortunately, I've never met a sane compiler.

  • Ian (unregistered)

    A looong time ago, I recall in some book with a name like "C++ for Dummies" or "The Complete Idiot's Guide to C++", there was a sidebar titled "How to Annoy a Visual Basic Programmer". It said (presumably in jest) that VB devs do "if x = True" while C++ devs do "if (x != false)". Maybe someone read that, took it seriously, and thought they'd be cute?

  • Argle (unregistered) in reply to pif

    Sure about that? If such a compiler existed, I assure you that a lot of programmers' brains will fry as they attempt a paradigm shift without a clutch.

  • Chatogaster (unregistered)
    Comment held for moderation.
  • (nodebb)

    This construct was written to deal with Schrodinger's Boolean.

  • Yikes (unregistered)
    Comment held for moderation.
  • network_noadle (unregistered) in reply to Argle

    We've heard of fuzzy logic; perhaps such a language has to allow for statements that are 'less than true' and 'more than false'. We should ask a lecturer in Woolly Thinking about this...

  • (nodebb) in reply to pif

    In general, I'd advocate going a step further and banning the comparison of boolean values (constants or not), as if (in C++ terms) bool operator ==(bool, bool) does not and cannot exist.

  • tbo (unregistered)

    While it's always fun to speculate, I have a hunch the answer is something much more mundane: style preference.

    If my shirt is not red, how did you parse this sentence?

    if ( shirt (is not) red ) or if ( shirt is (not red) ) ?

    There were probably just two different people who read the sentence differently.

  • holy shit now I'm actually commenting here... (unregistered) in reply to Steve_The_Cynic

    That would also make something like this impossible:

    if ((a > b) == (c < d))

    which does come in handy from time to time. I've used this more than once, if not with == then !=, but same difference. Without operator== you'd have to do the following, which I don't find more readable:

    var x = a > b;
var y = c < d;
if ((x && y) || (!x && !y))

    Yes, someone who genuinely needs to compare bools that way can be expected to come up with the alternative, but it doesn't convey the intent the same way.

    // let's see if I got those code blocks right... 🤞

  • Maarten (unregistered) in reply to I dunno LOL ¯\(°_o)/¯
    Comment held for moderation.
  • (nodebb) in reply to holy shit now I'm actually commenting here...

    Some languages have EQV and NEQV operators (or XOR) which are equivalent to comparison but more logical (aha).

    So you could have if (a EQV b). Anybody who writes if (a EQV True) should hopefully get a compiler warning for writing a stupid operation.

  • trends (unregistered) in reply to I dunno LOL ¯\(°_o)/¯
    Comment held for moderation.
  • Ray (unregistered)
    Comment held for moderation.
  • Chris (unregistered) in reply to holy shit now I'm actually commenting here...
    Comment held for moderation.
  • xtal256 (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to pif

    And you're unlikely ever to meet one, as first you'd have to have a sane language design.

  • A.C. (unregistered)
    Comment held for moderation.
  • Drak (unregistered)

    There's true, false and 'maybe'. 'Maybe' is not false, but also not true.

  • (nodebb) in reply to holy shit now I'm actually commenting here...

    That would also make something like this impossible:

    if ((a > b) == (c < d))

    That looks like an XNOR operation. Shame there isn't an actual factual boolean XOR in most C-ish languages. Would have been nice if K&R had given us a^b for bit XOR and a^^b for boolean XOR, so your operation would be:

        if ( !((a > b) ^^ (c < d)) )

    although I have seen people abusing C and C++'s silent promotion of bool to int to cheese it as (note single ^):

        if ( !((a > b) ^ (c < d)) )
  • HG (unregistered)

    I think this is the opposite of some Visual Basic / COM problem. I recall vaguely that some configuration of tech glue ends up with True being treated as 1, and False as 0, but sometimes COM APIs return some other non-zero value (like -1) for "true". Doing "<> False" may therefore be necessary, but I don't see why you'd need "<> True".

  • (nodebb) in reply to HG

    The low-level Win32 COM APIs return HRESULTs, which are a 32-bit unsigned integer value, with all "high-bit set" values indicating an error (and the rest of the bits identifying the error).

    High-bit clear indicates a success, which is usually S_OK (zero), but a few can return S_FALSE which is 1.

  • Worf (unregistered)
    Comment held for moderation.
  • Scepticals (unregistered)

    What would happen if EOF was (null)?

  • John Fat (unregistered) in reply to tbo

    Perl 6 actually lets you do exactly that - $x | $y is a value, represents a superposition of the two values, and can be used anywhere the values can, the result of which is another superposition. Then eventually you end up with a superposition of bools, which when evaluated in a boolean context collapse via OR. Or you can make the superposition with &, or ^, and there's even one for the NOT case, though unfortunately lacking a convenient operator.

  • (nodebb) in reply to Steve_The_Cynic

    That looks like an XNOR operation

    Why not call it what it is: an equality operator? There's no problem with == if your boolean type properly has only two values, nor != which is the same as xor. There is absolutely no problem with such things unless your type standing in for boolean is really an integer and that is the real WTF.

  • Max (unregistered) in reply to Prime Mover

    Are you, by any chance, referring to "Logics with Semiring semantics" ?

Leave a comment on “Accessible Booleans”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article