Alan Kay on the misunderstanding of OOP

You're right that message passing is a different way of looking at things; but obviously it's something different to method calls. Delegation, for one thing, is much easier with message passing, as are other strategies, like default implementations, remoting (never mind how poorly RPC scales), etc. On the other hand, getting two objects to communicate over a private channel can be more awkward, as they need to share pre-arranged references, rather than simply being friends / package / internal visibility, or similar visibility override.

http://www.iolanguage.com/

It pains me when people spend a fair amount of time coding Ruby, and then encounter metaprogamming and dynamic method invocation, and because of their wrong preconceptions they think it's deep, dark, super-genius hackery.

Unfortunately it gets clumsy to always say, "passes the message 'foo'" instead of "calls 'foo'", but if you can make the point early and toss in some reminders along the way the idea may stick.

Getter and setter methods on objects are like OK and Cancel buttons in dialogs. Just because it's uniform industry "best practice" doesn't make it not completely retarded and obscurantist.

Cocoa makes extensive use of delegates (not sure if these are similar to .net delegates) for handling unrecognised messages, which makes adding custom behaviour to classes possible without subclassing.

Rails is (in)famous for making use of Ruby's method_missing to implement all sorts of funky stuff.

This view is probably prevalent because C++ more or less does (and did even more in its early days) promote objects as structs with methods and some other fanciness on top, and C++ was probably the first really widespread OO language.

e.g.

    type Animal
    type Lion < Animal
    type Elephant < Animal
    type Giraffe < Animal

    method encounter(Animal, Animal)

    def encounter(Lion a, Giraffe b):
        // eat it

    def encounter(Lion a, Lion b):
        // fight

    type Animal
    type Lion < Animal
    type Elephant < Animal
    type Giraffe < Animal
    
    def encounter(Animal a, Animal b):
       if(a is Lion && b is Giraffe):
          // eat it
       else if(a is Lion && b is Lion):
          // fight
       else:
          raise NoApplicableMethodError

    def Prime(n): // primality testing algorithm here

    def Foo(Prime n): ...

    type Rectangle height width

    def Square(Rectangle r): height(r) == width(r)
    
    def Something(Square x): ...
    def Something(Rectangle x): ...

    def encounter(Lion a, Giraffe b) when isHungry(a): eat
    def encounter(Lion a, Giraffe b) when !isHungry(a): walk away

It's closely related to pattern matching in languages like Haskell, but that's usually not allowed to span multiple modules or files. And algebraic data types are closed, making it much less useful.