=== confusion

Discussion in 'Ruby' started by Ian Macdonald, Feb 9, 2004.

  1. Hello,

    After a couple of years of Ruby programming, I find that the ===
    operator still has the ability to occasionally confound me.

    Today, I had some code that looked like this:

    foo = case bar.class
    when Foo::Bar
    'abc'
    when Foo::Bar::Baz
    'def'
    when Foo::Qux
    'ghi'
    else
    'jkl'
    end

    The problem is that most comparisons of bar.class fell through to the
    else clause. A quick debugging session on a particular instance of 'bar'
    revealed that 'bar.class == Foo::Bar' was true, but
    'bar.class === Foo::Bar' was false. Quite honestly, I don't understand
    why, as I'm not overriding === anywhere. My classes are not derived from
    any standard Ruby classes, either, so they should be inheriting ===
    from Object, if I understand things correctly.

    I fixed it by changing the start of the case statement to
    'case bar.class.to_s' and then comparing to strings instead of object
    identifiers, but I would like to understand what exactly === was doing
    in the original case.

    Ian
    --
    Ian Macdonald | When neither their poverty nor their honor
    System Administrator | is touched, the majority of men live
    | content. -- Niccolo Machiavelli
    http://www.caliban.org |
    |
     
    Ian Macdonald, Feb 9, 2004
    #1
    1. Advertising

  2. Ian Macdonald

    George Ogata Guest

    Ian Macdonald <> writes:

    > foo = case bar.class
    > when Foo::Bar
    > 'abc'
    > when Foo::Bar::Baz
    > 'def'
    > when Foo::Qux
    > 'ghi'
    > else
    > 'jkl'
    > end
    >
    > The problem is that most comparisons of bar.class fell through to the
    > else clause. A quick debugging session on a particular instance of 'bar'
    > revealed that 'bar.class == Foo::Bar' was true, but
    > 'bar.class === Foo::Bar' was false. Quite honestly, I don't understand
    > why, as I'm not overriding === anywhere. My classes are not derived from
    > any standard Ruby classes, either, so they should be inheriting ===
    > from Object, if I understand things correctly.
    >
    > I fixed it by changing the start of the case statement to
    > 'case bar.class.to_s' and then comparing to strings instead of object
    > identifiers, but I would like to understand what exactly === was doing
    > in the original case.


    This keeps coming up from time to time.

    Module#=== returns true iff the argument is an instance of the module
    or one of its descendants (from the Pickaxe). In your code,
    `bar.class' returns an instance of `Class', which is of course not a
    descendant of `Foo::Bar', `Foo::Bar::Baz', etc., and so falls through
    to the else clause. I think what you want is to remove the `.class'
    in the case expression:

    foo = case bar
    ## ^^^^^^ (removed the `.class')
    when Foo::Bar
    'abc'
    when Foo::Bar::Baz
    'def'
    when Foo::Qux
    'ghi'
    else
    'jkl'
    end

    HTH
     
    George Ogata, Feb 9, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. martin f. krafft

    confusion when resetting registers

    martin f. krafft, Aug 18, 2004, in forum: VHDL
    Replies:
    2
    Views:
    471
    Paul Sereno
    Aug 19, 2004
  2. Peter Hermansson

    Procedures in testbench confusion

    Peter Hermansson, Aug 25, 2004, in forum: VHDL
    Replies:
    2
    Views:
    867
    Peter Hermansson
    Aug 25, 2004
  3. Chris

    defined() confusion

    Chris, Dec 11, 2003, in forum: Perl
    Replies:
    2
    Views:
    511
  4. Jerome

    runtime confusion

    Jerome, Dec 3, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    403
    Jerome
    Dec 3, 2005
  5. Chris Jackson

    MissingMethodException Confusion

    Chris Jackson, Jul 11, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    1,813
    Luke Zhang [MSFT]
    Jul 17, 2003
Loading...

Share This Page