Comment by Rich Demers

If you are building a VW image that will only be used for a single application (call it BF), then the technique of ad-hoc polymorphism that you describe here certainly works. But what if, at some point in the future, you decide that BF should be included as a component in a more comprehensive application, along with a variety of other components. It then become necessary to merge the extensions to Object and hope that they don't conflict in some way. And even if they do, class Object now has a variety of methods that have nothing to do with the essence of being "an Object." What once was simply a coding convenience has now become code pollution that makes understanding and maintenance of the larger system more difficult. Given that it is often difficult to know how a piece of code will be used in the future, I would suggest that this is not a particularly good thing to be doing -- or teaching -- at the least, not a "Best Practice."

Comment by James Robertson

In practice, how many applications will want to add #isFoo?

Yes, that's why we write tests and like access to the source, so we can do these things.

This is a heckuvalot better than Java where you have to write all kinds of "helper classes" (usually with "static methods" that are not object-oriented).