[git-pull]

It's the first time I heard of #doesNotUnderstand

Despite it looking cool and useful, IMO it's more of a (quite pleasant) sugar than an OOP concept. There's also a try/catch example where you'd get similar behavior.

I feel this is a bit opinionated:

> "but this is clearly rather verbose and it has to be repeated for every call."

I think the example in the link is what try/catch is meant for. Message passing systems in C/C++ handle situations where a disabled/unavailable service receives communication and recovers.

As for C++ and replacing objects:

I feel this is also a language-specific gotcha that doesn't hinder a learner understanding OOP. But C++ has many more gotchas than that.

For instance, there's no pure "interface" keyword. It can still be done (and is), code example: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., how Google Style guide defines it: https://google.github.io/styleguide/cppguide.html#Interfaces

[panic]

In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship.

The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime, not at compile time like Java or C++. Looking things up at runtime makes the system less efficient, but makes it easier to change pieces of the system independently.

[git-pull]

> In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile.

I read the page, I liked it. It shows a try/catch is how it'd be done.

> In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship.

I find that fascinating. But still, another case where it's more a rule and intricacy of the language.

This is the latest C++17 draft (2017-03-21) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465....

So here's why I go on about it being an intricacy of the language: The amount of casting / type rules and so on in C++, for instance, is mind-boggling.

> The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime

Which is interesting. And cool.

Isn't that similar to, an extent, virtual functions / vtable'd methods in C++?

But how does this wrap into C++ not handling an aspect of OOP? In your words. Even though I feel #doesNotUnderstand is a sugar and not necessarily a whole OOP concept, I think it can handled via an event system and try/catches.

[panic]

Here's a concrete example: say I want to write a class which wraps an object, logging all the methods called on it. So if I say (in C++-ish syntax):

    Dog *dog = new Dog()
    LoggingWrapper *wrapper = new LoggingWrapper(dog)
    wrapper->runAround()

The program should output a log entry like "Dog->runAround() called", then the dog should run around.

In Smalltalk, you can implement `LoggingWrapper doesNotUnderstand:` to output the log entry; something like:

    doesNotUnderstand: aMessage
        Logger log: target class, ' ', aMessage selector, ' called'.
        ^ aMessage sentTo: target.

It's not impossible to implement a class like LoggingWrapper using vtables -- in order to make a vtable, you have to know all a class's methods at compile time, but LoggingWrapper can respond to any method its target responds to.