• Rich (unregistered) in reply to Franz Kafka
    Franz Kafka:
    So, true = all bits set? I guess that makes sense to some MS freak that's retired by now.

    Lets you do cool things like

    Let x=(3 AND item$="hat")+(5 AND item$="shoe")

    Where and is bitwise.

    Rich

  • Ken Hagan (unregistered) in reply to Sven

    "Visual Basic (at least since version 4, and before the .Net stuff) is built on COM. And it just so happens that in COM, true is defined as -1. Go check the PSDK headers if you want: VARIANT_TRUE is -1 and VARIANT_FALSE is 0. This is the definition VB uses."

    I think you'll find that COM's definition was chosen to be compatible with even earlier versions of VB. In many ways, using "all 1 bits" is rather more consistent than "using one 1 bits". In any case, I think you'll find that C introduced the world to the idea that any non-zero value is true. (The C language has boolean expressions, but no boolean type. What's that all about?)

    (BTW, I speak as someone who likes C and dislikes VB. I'm just not religious about it.)

  • Zunrin (unregistered)
    The important part (for anyone that doesn't know) is that in Visual Basic, True is equivalent to negative one when you shove it through CInt. (When using System.Convert.ToInt32, you get positive one instead.)

    I think that they should review their code and choose one way of setting TRUE value to avoid problems. Using VB and VB.NET conventions at the same time is asking for trouble.

    Captcha: quake... Who wants to play? :)

  • Anonyposter (unregistered)

    Displaying 100Ks of records to a client application without filtering what is actually needed is a WTF born of laziness.

    A human can't process that much data, so it's best to let the database server do what it is meant for - get only the data you need and return that (smaller) data set to the client.

    If you need different data, then just query the thing again. If you use well-written SQL, that's not a problem. The problem happens when developers who don't truly understand databases start writing SQL and thinking it's better for the application to do data filtering and sorting, rather than the database server.

    That's what the database server is for. Use it wisely - don't treat it like a file, like most developers do...

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    This is nothing... really...:
    This explains a few things for me. I've been working on a legacy PHP app where -1 is true, 2 is false, and 0 is null. It would appear that the inspiration for this was in how Visual Basic handles booleans in the database. And I just thought the original system designer was insane.

    So, true = all bits set? I guess that makes sense to some MS freak that's retired by now.

    No, it makes sense to just about anybody. The only requirement for bool-true and bool-false is that they be logical inverses of eathother (and, outside the realm of WTFery, the only members of their set).

    In this case, it is much, much easier to map logical representation on to physical representation. Thus, 0xFFFF.... == ~0x0000.... Why twat around with arbitrary bit selections when your cpu instruction set is explicitly designed for this sort of thing?

    The result of a needless division between the logical and the physical, IMHO, is confusion and silliness:

    KattMan:
    Darren:
    As a long-suffering VB developer, I've always been amused by the plethora of options to express "nothingness".

    Let me see... <snip/>

    Actually those values you state are not equivalent to each other.

    IsNull is for a declared but Null initialized variable. Nothing is for a declared but non-instantiated object. = "" is purely for strings that have been initialized but contain an empty string.

    IsEmpty() is a weird one to most, remember this is a function. It returns True for non-initialized variables, and False for all others. Non-initialized means one that has simply been dimmed or reset to it's original state by being assigned Empty. Assigning a value, even Null, makes this return False.

    These are not nothingness in the purest sense of the word. If you think of the very lowest level you can relate it to C. = "" means a string with only the null terminator, but this at least is a value. IsNull means it is pointing to a memory location with the Null value in it. Non-initialized means the memory is pointed to, but who knows what is there.

    Please note that I am suggesting that VB is silly here, not that KattMan is. (I'm very taken with the idea of "nothingness in the purest sense of the word.")

    It's a little disingenuous to point out that "these values are not equivalent to each other." I mean, that's the whole point, isn't it? If they were equivalent, you'd only need one (plus, of course, FILE_NOT_FOUND).

    In the real world (ie the application domain, not the programming domain), who the hell needs to hold all four separate concepts in their head? When does one apply? When does another? The difference between "Nothing" and "Null" is particularly non-intuitive. Throwing in a function, IsEmpty(), is not helpful. This is a crass and objectionable language design.

    (It should be noted that Perl, for example, suffers from similar problems. You don't have to hate an entire language. You can pick and choose, by feature.)

    Anyway, to follow KattMan's logic, why would a programmer in a high-level language be overly concerned by the exact physical representation of a boolean? (Provided it works correctly. Which in VB, without excruciating care, it seems that it does not.)

  • (cs) in reply to AN

    What's the boolean value of MAYBE in VB?

    Not that I'd really want to know. Just curious.

  • (cs) in reply to Sven
    Sven:
    Actually it's not VB's fault that True is -1.

    Visual Basic (at least since version 4, and before the .Net stuff) is built on COM. And it just so happens that in COM, true is defined as -1. Go check the PSDK headers if you want: VARIANT_TRUE is -1 and VARIANT_FALSE is 0. This is the definition VB uses.

    Actually, it is VB's fault.

    You are aware that VB existed prior to verion 4, aren't you?

    You are aware that VB started as a 16-bit language, aren't you?

    You are aware that VB actually predates COM, aren't you?

    You are aware that COM's design was, to a large extent, a reaction to the VBX (Visual Basic Extensions) components (which didn't work very well any more when you shifted fom 16-bit VB to 32-bit VB).

    COM's True value is a result of VB. Not the other way round. Oh, and that silly 16-bit integer size in VB5? Yep, due to the way that VB started out as a 16-bit language.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Anyway, to follow KattMan's logic, why would a programmer in a high-level language be overly concerned by the exact physical representation of a boolean? (Provided it works correctly. Which in VB, without excruciating care, it seems that it does not.)

    Actually I totally agree with this one. In higher level languages we are usually only concerned if a value has been initialized or not and if that value is null or not. This could drop us to Is Nothing and Is Null without any other concern.

    As far as VB Booleans not working correctly, well they work correctly within VB. Please not that earlier I mentioned that my Booleans were pure bi-valued booleans and nothing more, I also kept them contained within VB. Anything that needed to communicate outside of VB had these values converted to 0 = False and 1 = True. So perhaps I protected myself from any strange behavior with intercommunications with other processes.

  • Alex Brown (unregistered) in reply to Anonyposter
    Anonyposter:
    Displaying 100Ks of records to a client application without filtering what is actually needed is a WTF born of laziness.

    A human can't process that much data, so it's best to let the database server do what it is meant for - get only the data you need and return that (smaller) data set to the client.

    If you need different data, then just query the thing again. If you use well-written SQL, that's not a problem. The problem happens when developers who don't truly understand databases start writing SQL and thinking it's better for the application to do data filtering and sorting, rather than the database server.

    That's what the database server is for. Use it wisely - don't treat it like a file, like most developers do...

    You sir, are an idiot.

  • (cs) in reply to KattMan
    KattMan:
    real_aardvark:
    Anyway, to follow KattMan's logic, why would a programmer in a high-level language be overly concerned by the exact physical representation of a boolean? (Provided it works correctly. Which in VB, without excruciating care, it seems that it does not.)

    Actually I totally agree with this one. In higher level languages we are usually only concerned if a value has been initialized or not and if that value is null or not. This could drop us to Is Nothing and Is Null without any other concern.

    As far as VB Booleans not working correctly, well they work correctly within VB. Please not that earlier I mentioned that my Booleans were pure bi-valued booleans and nothing more, I also kept them contained within VB. Anything that needed to communicate outside of VB had these values converted to 0 = False and 1 = True. So perhaps I protected myself from any strange behavior with intercommunications with other processes.

    Which means that it is possible to program correctly in VB. As we've all known (one or two posters notwithstanding).

    However, and at the risk of hammering this one into the ground, not every VB programmer is as careful about encapsulation as you are -- which accounts for a large proportion of VB WTFs on this site. I contend that VB on its own (16 bit, 32 bit, 43.5 bit, VB5, VB4--, whatever) is a language ill-suited to good programming style.

    VB.Net, on the other hand, may well be a significant improvement in this respect. Unfortunately, as far as I'm concerned, it loses in so many other respects that it really isn't an adequate step forward.

  • Sven (unregistered) in reply to Bellinghman
    Bellinghman:
    Sven:
    Actually it's not VB's fault that True is -1.

    Visual Basic (at least since version 4, and before the .Net stuff) is built on COM. And it just so happens that in COM, true is defined as -1. Go check the PSDK headers if you want: VARIANT_TRUE is -1 and VARIANT_FALSE is 0. This is the definition VB uses.

    Actually, it is VB's fault.

    You are aware that VB existed prior to verion 4, aren't you?

    You are aware that VB started as a 16-bit language, aren't you?

    You are aware that VB actually predates COM, aren't you?

    Yes, I've used it since VB3 (and I think I've got a copy of VB for DOS somewhere too).

    Bellinghman:
    You are aware that COM's design was, to a large extent, a reaction to the VBX (Visual Basic Extensions) components (which didn't work very well any more when you shifted fom 16-bit VB to 32-bit VB).
    Of that I was not aware, and I appreciate the correction.

    I knew about the 16-bit Integer though, and am very glad they changed that for VB.NET.

    I started my programming life in GW-BASIC, and still have a bit of a soft spot for, regardless of the prejudices associated with the language. Although I can write numerous other languages including Java and C# and can argue the finer points of ISO standard C++, I still like VB. For ASP.NET and Windows Forms development, it remains my preferred language (mainly because of the WithEvents syntax). Yes, I know you can write terrible code in VB (I can't look at code I wrote a decade ago without cringing (in my defense, I was 15)). But everybody's gotta start somewhere.

    If that makes me less "cool" or whatever in the eyes of some, so be it.

  • (cs) in reply to real_aardvark
    real_aardvark:
    <snip/>

    Please note that I am suggesting that VB is silly here, not that KattMan is. (I'm very taken with the idea of "nothingness in the purest sense of the word.")

    It's a little disingenuous to point out that "these values are not equivalent to each other." I mean, that's the whole point, isn't it? If they were equivalent, you'd only need one (plus, of course, FILE_NOT_FOUND).

    In the real world (ie the application domain, not the programming domain), who the hell needs to hold all four separate concepts in their head? When does one apply? When does another? The difference between "Nothing" and "Null" is particularly non-intuitive. Throwing in a function, IsEmpty(), is not helpful. This is a crass and objectionable language design.

    It gets better: In VBScript (at least, maybe also VBA) Nothing is an assigned value, just like Null. Simply declaring a variable lets IsEmpty() return True (or -1 if you prefer), but it Is Not Nothing at that time. Dereferencing an object (like a class or COM object) by using Set obj = Nothing is the only way to get a variable reporting its Nothingness correctly.

  • grelmsch (unregistered)

    Using "Boolean" columns in SQL tables is like a code smell. It wouldn't surprise me if there were also an IsRegistered and an IsCanceled column. Might be better to come up with an encoding scheme and use a status code column.

Leave a comment on “SQL Four Joy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article