If Not foo Is Nothing...



  • I recently saw some Basic code (LotusScript, to be precise) containing clauses of the form

    If Not foo Is Nothing Then
       stuff
    End If
    
    which looks like a verbose way to say
    If foo Then
       stuff
    End If
    
    It looks like a WTF to me but I have to ask, is there any sane reason someone would do this?


  • The programmer is probably coming from a strongly-typed language in which Nothing doesn't convert to False.  I know I've written VB.NET code like that--with Option Strict on, I believe it's the only way you can check for nulls.

    (In fact, the language designers added a new operator, IsNot, to make the check for null a little nicer.  e.g. If foo IsNot Nothing Then).


  • ♿ (Parody)

    This is required for VBS/VBA/VB6. An Object cannot be implicitly converted to a boolean expression.



  • @Zak said:

    If Not foo Is Nothing Then
    stuff
    End If


    Somehow, the following comes to mind...
    If foo Is Something Then
    stuff
    End If



  • To second the general theme of the replies, in Java you can't do something like

    if (foo)
    {
        stuff;
    }

    unless foo is of type boolean. (Even objects of type Boolean can't be used that way - you'd have to do foo.booleanValue()).

    So yes, there is a sane reason why someone would do that, particularly if they come from a strongly-typed language background. Even failing that, it's just plain clearer, imho, but I concede that that's arguable.



  • @Cloaked User said:

    Even objects of type Boolean can't be used that way - you'd have to do foo.booleanValue())


    I'm so happy I do Perl... I mean, OK have your poncy strong typing if you like but having to ask a boolean value for its boolean value? wtf?!!

    I love being able to implicitly treat objects as strings as numbers as - what am I saying, in Perl strings and numbers are the same anyway... I like it 'cos it doesn't treat me like a baby coder, it's about as close as I get to good old assembler these days.



  • @versatilia said:

    @Cloaked User said:
    Even objects of type Boolean can't be used that way - you'd have to do foo.booleanValue())


    I'm so happy I do Perl... I mean, OK have your poncy strong typing if you like but having to ask a boolean value for its boolean value? wtf?!!

    I love being able to implicitly treat objects as strings as numbers as - what am I saying, in Perl strings and numbers are the same anyway... I like it 'cos it doesn't treat me like a baby coder, it's about as close as I get to good old assembler these days.

    <FONT face=Arial>You have to ask a Boolean value for it's boolean value.  Boolean (with caps) is an object to encapsulate a boolean (without caps).  Normally, you just use the boolean unless you wrapped it up in an object to take advantage of polymorphism (putting it in something like a stack).</FONT>

    <FONT face=Arial>Having strings and numbers as the same thing is nothing like assembler.</FONT>



  • @Eric Shinn said:

    @versatilia said:

    @Cloaked User said:
    Even objects of type Boolean can't be used that way - you'd have to do foo.booleanValue())


    I'm so happy I do Perl... I mean, OK have your poncy strong typing if you like but having to ask a boolean value for its boolean value? wtf?!!

    I love being able to implicitly treat objects as strings as numbers as - what am I saying, in Perl strings and numbers are the same anyway... I like it 'cos it doesn't treat me like a baby coder, it's about as close as I get to good old assembler these days.

    <font face="Arial">You have to ask a Boolean value for it's boolean value.  Boolean (with caps) is an object to encapsulate a boolean (without caps).  Normally, you just use the boolean unless you wrapped it up in an object to take advantage of polymorphism (putting it in something like a stack).</font>

    <font face="Arial">Having strings and numbers as the same thing is nothing like assembler.</font>

    [owen@verdandi autobox]$ cat Box.java
    public class Box {
        public static void main (String... args) {
            Boolean b = true;
            if (b)
                System.out.println ("b is automatically unboxed.");
        }
    }
    [owen@verdandi autobox]$ javac Box.java
    [owen@verdandi autobox]$ java Box
    b is automatically unboxed.
    [owen@verdandi autobox]$

    Java 1.5 was only released a year and a half ago.  You'd think these criticisms would be replaced with more recent ones (like some of the ambiguity autoboxing introduces).



  • @versatilia said:

    I'm so happy I do Perl... I mean, OK have your poncy strong typing if you like but having to ask a boolean value for its boolean value? wtf?!!

    I love being able to implicitly treat objects as strings as numbers as - what am I saying, in Perl strings and numbers are the same anyway... I like it 'cos it doesn't treat me like a baby coder, it's about as close as I get to good old assembler these days.

    I should have been able to figure out my original question. Thanks, everyone for the sane answers.

    I'm so happy I do Lisp.



  • ...unless somebody else wrote it, and you have to figure out what might get stored in it.



  • @Carnildo said:

    You know, that's another thing I like about Perl:

    push @myStack, 17;
    push @myStack, $aVariable;
    push @myStack, 42;
    push @myStack, \@anotherStack;
    push @myStack, \%associativeArray;
    push @myStack, $anObject;
    push @myStack, \&aFunction;
    push @myStack, sub {$_[1] == $_[0]}; # This one's an anonymous function
    push @myStack, undef;
    

    is perfectly good code.

    It's perfectly valid code... I'm not sure I'd call it good.



  • @Carnildo said:

    You know, that's another thing I like about Perl: push @myStack, 17; push @myStack, $aVariable; push @myStack, 42; push @myStack, @anotherStack; push @myStack, %associativeArray; push @myStack, $anObject; push @myStack, &amp;aFunction; push @myStack, sub {$[1] == $[0]}; # This one's an anonymous function push @myStack, undef; is perfectly good code.
    <FONT face=Arial>I've only dabbled in Perl...is it strongly typed (i.e., is the information about what type of object stored with the object in that stack)?</FONT>



  • @versatilia said:

    ...in Perl strings and numbers are the same anyway...

    Actually, they aren't quite. For example, 0 and "0" may both be false, as is 0.0, but "0.0" is true.

    Nyah.

    Incidentally, "0 but true" is also true, but that's a whole other thread right there.

    I second the "happy I do perl" sentiment, mind, even if it is littered with odd special cases. They may steepen the learning curve, but they can be very useful.



  • @versatilia said:

    I'm so happy I do Perl...


    Perl's nice but it has its fair share of true and false quirks too. Such as why "0" is false. "" is false as well, which is of course useful if you're reading in lines from a file...... I think you have to use &defined for that, but I think it does it automagically now too. I forget.

    Ruby's nice too:
    if 0
        puts "0 is true, callay, calloo"
    end



  • @Eric Shinn said:

    <font face="Arial">Having strings and numbers as the same thing is nothing like assembler.</font>



    I think what he meant was that in Assembler, there are no specific data-types, and everything is stored as a numerical value: pointers, characters, numbers, etc.  And the type is determined by context at the moment of operating on the data.  Perl is not really like this, it just guesses the type of each value by the context of the operations, and does a pretty good job at this.

    But in a sense, the concept that data is just data, and that type is only important in the context of the operations upon such data (determined either by the programmer, or by a smart interpreter), is shared by both Perl and Assembler.  And as the parent poster mentioned, its refreshing to not have a language impose strict typing rules in order to protect you from yourself; it offers the ability to create a more intuitive code flow.   Take this simple code, for example:

    <font face="Courier New">    $foo = $user_input_value;  # Its a string!
        $foo++;                    # Its a number!
        if ($foo) {                # Its a boolean!
            print "$foo\n";        # And a string again!
        }
    </font>
    I do love Perl.  And Assembler, too.

        dZ.



  • That's because, although Perl's definition of an array may seem too liberal, its still as string as in any other language; it just looks that way.

    Perl arrays are indeed a list of like items.  In your example, references, numbers, strings, lions, and bears, are all of the same basic type:  scalars, which is one of the very few "intrinsic" data-types in Perl.


        -dZ.


Log in to reply