Visual Basic WTF



  • I found this while digging through the MSDN library.  Looks like they beat us to it!



  • What they have there is some kind of implicit cast to boolean

    Anyway, it looks funny. I'm nearly shocked that you must define both IsTrue and IsFalse, doesn't the compiler know about the magical NOT operator?



  • Excellent!  So we could make this (pseudo-pseudo-code)



    class WTF {

       method IsTrue(x) {

           if fileNotFound(x) {

              return true;

          }elsif fileFound(x) {

              return false;

          }else{

              return other;

    ...




  • Oh. My. Pants.

    That's awesome, I thought there were enough WTF's with VB on its own, but Microsoft is now holding our hand on the road to WTFville. As an interesting point of reference for that function, the sample doesn't exactly tell you how to determine the true-ness (or lack thereof) of your parameter. Hopefully this will minimize the damage done by idiot programmers, because anyone stupid enough to use this code won't be able to figure it out.



  • Maybe I'm just dense, but I don't see how the IsTrue operator is a WTF.
    (Requiring that there also be IsFalse is definitely a WTF - was that
    what caught your eye? I wonder if you can just define IsFalse as Not
    IsTrue?) Defining this implicit operator makes it possible to evaluate
    an object of your class in a boolean context. What's wrong with that?
    What am I missing?



  • I agree.  It's a shorthand mechanism for allowing the definition of some set of conditions to let an object evaluate to true.  And the IsFalse doesn't necessarily have to be Not IsTrue. 



  • @kmerkle said:

    And the IsFalse doesn't necessarily have to be Not IsTrue. 



    Uhm, I'm pretty sure it does, if we are talking about Boolean values.  IsFalse must always be the opposite of IsTrue if we are preserving the concept of what a Boolean value is.  I mean, what exactly does it mean if something IsTrue and IsFalse at the same time?!



  • @Grimoire said:

    @kmerkle said:

    And the IsFalse doesn't necessarily have to be Not IsTrue. 



    Uhm, I'm pretty sure it does, if we are talking about Boolean values.  IsFalse must always be the opposite of IsTrue if we are preserving the concept of what a Boolean value is.  I mean, what exactly does it mean if something IsTrue and IsFalse at the same time?!

    FileNotFound!



  • Wait, no.  If they are both true, then FileFound.  If they are both false, then FileNotFound.



  • I agree partially. Casting a random class to a boolean certainly makes sense, since it eliminates the need of building explicit (pseudo code)

    if (myobject.was_inited_successfully) {
        do-rest-of-code
    } else {
        throw-some-warning
    }

    However, I do agree that false === !true. Therefore, should you want to implement such a feature in your language, I'd say you'd have to do it something along the lines of (pseudo code, I'm really really really never touching VB again):

    class myclass
    {
    public operator castBool()
    {
        if (whatever_check_you_want_to_make) {
           return true;
        }
        return false;
    }
    }




  • For what it's worth, I think it's reasonable to assume that the
    assumption that true == !false is baked into the VB compiler all over
    the place. Unless I'm missing something, it doesn't look like it
    enforces that invariant, but I can't imagine you'd get sensible results
    if you violated it.

    A possible justification for this design
    would be the flexibility to define IsTrue as Not . IsFalse, where
    IsFalse is more convenient to implement.



  • I agree with nomelodies – this probably shouldn't be IsTrue() and IsFalse(), there should just be a single cast<Bool>() (or WTFever the syntax is in your poison of choice) method.



  • er, "Monomelodies". Strangely, you can't see the poster name of who you're replying to when you click "reply". I'm not going to go down the hackneyed route of "the real WTF is...", but we all know it's true.



  • @jesuswaffle said:


    A possible justification for this design
    would be the flexibility to define IsTrue as Not . IsFalse, where
    IsFalse is more convenient to implement.




    WTF?



    What's wrong with

    Return Not b




  • @Irrelevant said:

    er, "Monomelodies". Strangely, you can't see the poster name of who you're replying to when you click "reply". I'm not going to go down the hackneyed route of "the real WTF is...", but we all know it's true.


    I'm guessing the idea is to click "reply" for a general reply to the topic, and "quote" to actually quote someone. All the same, it doesn't make much sense from the user's perspective... took me some time to figure what exactly I was expected to do :)



  • @ammoQ said:

    @jesuswaffle said:

    A possible justification for this design
    would be the flexibility to define IsTrue as Not . IsFalse, where
    IsFalse is more convenient to implement.




    WTF?



    What's wrong with

    Return Not b




    What's *really* interesting - I just realised after a few glasses of alcohol - is what the return value of isFalse is supposed to be. Instinctively, I'd say isFalse returns true when the parameter passed is indeed false... knowing M$ though it'll be the other way around :P
    (and no, I can't be bothered to check up on this in MSDN - I'm still waaaay too glad I've nothing to do with those people anymore except for IE)


  • I guess none of you have used the SqlBoolean type in .NET.

    That's what I originally thought the original post was about when I clicked on the link.

    Just let this sink in for a moment, and then imagine the kind of WTF code you could write:

    Property Value

    true if Value is False; otherwise, false.

     

     



  • @don said:

    Maybe I'm just dense, but I don't see how the IsTrue operator is a WTF. (Requiring that there also be IsFalse is definitely a WTF - was that what caught your eye? I wonder if you can just define IsFalse as Not IsTrue?) Defining this implicit operator makes it possible to evaluate an object of your class in a boolean context. What's wrong with that? What am I missing?

    I think it qualifies for two reasons.  First, if I were to use something like this, it would likely only be to use the C-style of null evaluation.  As in, if (myObj) ...

    But, since I can't do that (WTF #1), it leads me to my second WTF reason, which is, why else is this a good idea??  I can't even imagine the genius that thought, "Hey Bill! We can make non-logical classes act like logical classes based on any arbitrary criteria the developer can invent!  Brillant!!"



  • Ignore WTF reason #1...  I guess I technically could use it as a C-style construct.

    I would have just edited my post, but...  erm...  yeah.



  • @bullseye said:

    why else is this a good idea??





    I, um...can't actually think of a case where defining a boolean
    property of the class wouldn't be better.Or at least more readable.



  • @A Wizard A True Star said:

    I guess none of you have used the SqlBoolean type in .NET.

    http://msdn2.microsoft.com/en-us/library/system.data.sqltypes.sqlboolean.isfalse(VS.80).aspx

    That's what I originally thought the original post was about when I clicked on the link.

    Just let this sink in for a moment, and then imagine the kind of WTF code you could write:

    Property Value

    true if Value is False; otherwise, false.

     


    What's interesting is the "Remarks" section:

    @MSDN said:


    Remarks

    If the Value is Null, this property still will be false.

    Assuming that IsTrue(null) == false as well, that means that IsTrue is in fact not equivalent to !IsFalse...



  • @Anonymouse said:

    What's interesting is the "Remarks" section:

    @MSDN said:


    Remarks

    If the Value is Null, this property still will be false.

    Assuming that IsTrue(null) == false as well, that means that IsTrue is in fact not equivalent to !IsFalse...



    I saw something somewhere that VB has an "Any" type.

    Seriously.

    Dim FortyTwo As Any

    That would sorta be a !null (or rather, a !Nothing)

    Wouldn't not it not? No?


  • @dhromed said:

    @Anonymouse said:

    What's interesting is the "Remarks" section:

    @MSDN said:


    Remarks

    If the Value is Null, this property still will be false.

    Assuming that IsTrue(null) == false as well, that means that IsTrue is in fact not equivalent to !IsFalse...



    I saw something somewhere that VB has an "Any" type.

    Seriously.

    Dim FortyTwo As Any

    That would sorta be a !null (or rather, a !Nothing)

    Wouldn't not it not? No?

    So now Homer has an 'Any' type to go with the 'Any' key, brillant!


  • @Anonymouse said:

    @A Wizard A True Star said:

    I guess none of you have used the SqlBoolean type in .NET.

    http://msdn2.microsoft.com/en-us/library/system.data.sqltypes.sqlboolean.isfalse(VS.80).aspx

    That's what I originally thought the original post was about when I clicked on the link.

    Just let this sink in for a moment, and then imagine the kind of WTF code you could write:

    Property Value

    true if Value is False; otherwise, false.

     


    What's interesting is the "Remarks" section:

    @MSDN said:


    Remarks

    If the Value is Null, this property still will be false.

    Assuming that IsTrue(null) == false as well, that means that IsTrue is in fact not equivalent to !IsFalse...



    This is really just .NET trying to cope with an SQL tristate (nullable) boolean.  There's an IsNull as well, and one of the three is always true.  So:

    IsTrue == !IsFalse && !IsNull
    IsFalse == !IsTrue && !IsNull
    IsNull == !IsTrue && !IsFalse

    This is pretty much par for the course for any language dealing with SQL, although it doesn't look like there's an overridable version of it (like the IsTrue in the top post.)

    I'm actually pretty sure that VB not supporting custom tristate logic is a good thing overall, although just think of the WTFs we're missing out on!

    (Also, this is my first post.)


  • @Jade E. said:


    This is really just .NET trying to cope with an SQL tristate (nullable) boolean.  There's an IsNull as well, and one of the three is always true.  So:

    IsTrue == !IsFalse && !IsNull
    IsFalse == !IsTrue && !IsNull
    IsNull == !IsTrue && !IsFalse

    This is pretty much par for the course for any language dealing with SQL, although it doesn't look like there's an overridable version of it (like the IsTrue in the top post.)

    I'm actually pretty sure that VB not supporting custom tristate logic is a good thing overall, although just think of the WTFs we're missing out on!

    (Also, this is my first post.)


    I wonder if anyone has ever tried to implement something like that by referencing the other functions.

    isTrue(Boolean b)
    {
        return !isFalse(b) && !isNull(b)
    }

    isFalse(Boolean b)
    {
        return !isNull(b) && !isTrue(b)
    }

    isNull(Boolean b)
    {
        return !isTrue(b) && !isFalse(b)
    }


    That would be amusing... until the program fell over.



  • @Monomelodies said:


        if (whatever_check_you_want_to_make) {
           return true;
        }
        return false;


    slap

    <font face="Courier New">return (whatever_check_you_want_to_make);</font>




  • @bullseye said:

    But, since I can't do that (WTF #1), it leads me to my second WTF reason, which is, why else is this a good idea??  I can't even imagine the genius that thought, "Hey Bill! We can make non-logical classes act like logical classes based on any arbitrary criteria the developer can invent!  Brillant!!"

    Are non-logical classes the same as illogical classes?



  • Was that posted on MSDN on April 1st?



  • @ammoQ said:

    I'm nearly shocked that you must define both IsTrue and IsFalse, doesn't the compiler know about the magical NOT operator?


    I'll bet the rationale (if there was one) is that computing one or the other may be more natural than the other and slightly more efficient, but you might not be able to say in general which that was.  That is, if it's naturally easier in one scenario to compute whether something is false, but you only allowed them to implement IsTrue, you'd be forced to add a Boolean negation to the computation of IsTrue.  This would make there be two negations to compute IsFalse when it could instead be done with none.  Therefore, they leave it up to the implementer to determine the most efficient way to do it.

    Of course, that presumes your developers know what they're doing.  Very often they don't, and some lanugages seem to attract those more than others...


Log in to reply