Comments on Sandi Metz: Ruby case statements and kind_of?

NIce article, and yes I dont yet feel it in my bon...

2011-11-04T04:35:36.075-04:00

NIce article, and yes I dont yet feel it in my bones. I guess need to really believe in what i am doing.

2011-11-04T04:33:50.618-04:00

This comment has been removed by the author.

Technically, you're not dealing with a double-...

2009-07-07T15:30:45.522-04:00

Technically, you're not dealing with a double-dispatch problem here. Double dispatch occurs when you have TWO objects which should determine which implementation of a method to call; "double" only depends on the type of its receiver (since it has no arguments).

The "CollideWith" method in the Wikpedia article is a double-dispatch issue because to know which one of the four implementations to call, you need to examine BOTH the type of the asteroid AND and the type the spaceship. C++ (and Java and Ruby) cannot do this on its own; it'll handle a dispatch on the receiving object, but in the general cases, the programmer will have to handle dispatching on the argument.

That being said, the visitor pattern IS a solution for this "double" method, and all the issues raised here are perfectly valid. It's just not technically a double-dispatch issue.

@Aaron, modifying core classes in gems is somethin...

2009-06-20T18:10:02.533-04:00

@Aaron, modifying core classes in gems is something I'm cautious of, but in application code I do it regularly without incident. And don't forget that Ruby gives us the option of modifying an individual object, limiting the potential scope for error even further.

Naming collisions don't come up nearly as ofte...

2009-06-18T12:27:58.563-04:00

Naming collisions don't come up nearly as often as critics suggest.

You could avoid reopening these classes if you wanted to, wrapping them with an object that implements double and then delegates the rest to the original object.

Anyway, the principle at work here is the Open-Closed principle. With the original case-based implementation, if you want to extend the behavior by adding a new type, you would have to modify the original code. Bad.

Nice post :)

Hopefully. I could be wrong. ;-) Here is a simp...

2009-06-17T13:51:40.755-04:00

Hopefully. I could be wrong. ;-)

Here is a simplified implementation of the double dispatch / visitor pattern I typically use:

http://gist.github.com/131378

When it calls "send", it's still examining the type in order to figure out which method to dispatch. IIRC, if I was doing this in Java, I would have to implement a "visit" method for each type I expect to receive. In ruby I cheat by using the class name in the method call, but I'm still asking the object for it's type.

Are we talking about the same thing?

Hmm, I see double-dispatch as avoiding the ...

2009-06-17T13:38:02.620-04:00

Hmm, I see double-dispatch as avoiding the problem of having to examine the type of any object. Are we talking about the same thing? Can you post an example to help me understand what you're saying?

Yes. I use double dispatch heavily for writing vi...

2009-06-17T13:27:51.573-04:00

Yes. I use double dispatch heavily for writing visitors, usually when dealing with ASTs. It would be nice if all objects had an "accept" method for doing this pattern. The only problem is, we have to examine the type, and isn't that what we're trying to avoid?

Smalltalk has a pattern which allows adding this k...

2009-06-17T12:57:39.726-04:00

Smalltalk has a pattern which allows adding this kind of behavior while avoiding method naming collisions.

It's called double-dispatch and basically it involves creating somewhat ugly, but unique, method names by using a namespace (usually something about the original receiver) to make the method names unique.

The technique is used extensively in Smalltalk. It works. I'd like to think we can use it in Ruby to make our code more OO and save us some pain.

Would some form of double-dispatch solve the problem you see?

Name collisions in particular. To me, adding meth...

2009-06-17T12:39:33.591-04:00

Name collisions in particular. To me, adding methods to core classes is like modifying a global variable. It's especially painful when your implementation of "double" doesn't agree with mine. Take your modification of the Array class for example. Array responds to "*", so it may be perfectly reasonable to think that the implementation of Array#double would be "self * 2". Which one is right? IMHO, neither should be added.

Take it one step further. What if I packaged my implementation of Array#double in a gem, and my gem depended on that functionality but you didn't know that! Redefining that method could have unexpected results. A prime example of this problem would be the native YAML gem vs. ActiveSupport's YAML generator. They both extend core classes, and have slightly different API's. Because of that do not play nicely together at all.

Switching on class type seems like a hack because we really should be duck typing, but extending core classes seems dangerous. Unfortunately I don't have a "good" solution. Subclasses or module extension maybe?

@Aaron Can you articulate why you feel that pain? ...

2009-06-17T12:15:48.665-04:00

@Aaron Can you articulate why you feel that pain? Fear of method naming collisions, or something else?

Arg! I completely agree with you, but it pains me...

2009-06-17T12:14:02.729-04:00

Arg! I completely agree with you, but it pains me to see methods added to core classes. Unfortunately, in this case, I can't think of a better way.