Does case/when really use ===?

[eden li]

Can someone explain why my class's === method is never called in the
following code?

irb(main):001:0> class C; def ===(k); puts "===(#{k.inspect}) called";
true; end; end
=> nil
irb(main):002:0> case C.new; when String; 'is a String'; else; 'not a
String'; end
=> "not a String"

I expected "===(String) called" to be printed out somewhere, somewhat
like:

irb(main):003:0> C.new === String
===(String) called
=> true

Am I misunderstanding how case/when works?

 

[Farrel Lifson]

Can someone explain why my class's === method is never called in the
following code?

irb(main):001:0> class C; def ===(k); puts "===(#{k.inspect}) called";
true; end; end
=> nil
irb(main):002:0> case C.new; when String; 'is a String'; else; 'not a
String'; end
=> "not a String"

I expected "===(String) called" to be printed out somewhere, somewhat
like:

irb(main):003:0> C.new === String
===(String) called
=> true

Am I misunderstanding how case/when works?

In case statements such as
case(object)
when otherObject
puts "Match!"
else
puts "No match"
end

The === is not called on object but rather on otherObject.

Farrel

 

[Sylvain Joyeux]

case bla
when Foo
end

calls Foo === bla, not bla === Foo

 

[Ken Bloom]

Can someone explain why my class's === method is never called in the
following code?

irb(main):001:0> class C; def ===(k); puts "===(#{k.inspect}) called";
true; end; end
=> nil
irb(main):002:0> case C.new; when String; 'is a String'; else; 'not a
String'; end
=> "not a String"

I expected "===(String) called" to be printed out somewhere, somewhat
like:

irb(main):003:0> C.new === String
===(String) called
=> true

Am I misunderstanding how case/when works?

=== is not commutative (nor is it intended to be), and it actually gets
called in the other direction (the call it makes is String === C.new)

To test how this works:

class Class
alias_method ld_case_equals, :===
def ===(other)
puts "In Class.===: #{inspect}===#{other.inspect}"
old_case_equals(other)
end
end


be forewarned that doing something like this in IRB will cause very wierd
output, since irb uses this method internally.

--Ken

 

[eden li]

Got it.

This question came up because I was dealing with a library that has
wrapped a proxy class around an Array that intercepted methods to make
it appear as if that class is actually an Array class (rails'
AssociationProxy for those counting). Because I'm not native in Ruby,
I spent a good deal of time debugging a particular case/when statement.

This proxy class undefines all non-critical instance method (ie, ones
that Ruby does not throw an error for when you call undef_method on
them) and passes them to an internal instance variable on
method_missing. This makes it seem like an object of this proxy class
look like an instance of its internal variable, but only until you pass
it to the case/when construct.

This makes me wonder how the proxy class could be rewritten to make
case/when operate on that internal variable.

Is rewriting the Class.=== method to special-case the proxy class the
only way to accomplish this?

 

[Xavier Noria]

This question came up because I was dealing with a library that has
wrapped a proxy class around an Array that intercepted methods to make
it appear as if that class is actually an Array class (rails'
AssociationProxy for those counting). Because I'm not native in Ruby,
I spent a good deal of time debugging a particular case/when
statement.

This proxy class undefines all non-critical instance method (ie, ones
that Ruby does not throw an error for when you call undef_method on
them) and passes them to an internal instance variable on
method_missing. This makes it seem like an object of this proxy class
look like an instance of its internal variable, but only until you
pass
it to the case/when construct.

This makes me wonder how the proxy class could be rewritten to make
case/when operate on that internal variable.

In fact, why not just subclass Array?

Which is the benefit of pretending to be an Array to the point that
AssociationProxy#class returns Array? People get confused with a
different find/select in those "arrays", case/when behaves
unexpectedly, ..., is there some technical reason a subclass wouldn't
work or would have other sort of drawbacks that weight more?

-- fxn