To be fair, method_missing has caused more nightmares and problems with debugging than probably any other feature in Ruby. I actively avoid using it, and even the Rails team has massively dialed back on its use in their libraries over the years...
I find this quite amusing because method_missing? has always been the difference between 'true' OO languages Smalltalk/Ruby and pseudo-OO language like C++; with the implication that true OO is better than pseudo OO for the ones making such distinction..
There has never been a "true" OO language. And if it there was, Smalltalk was not it. Alan Kay did coin the term, but Simula existed long before Smalltalk. The tree of languages that include C++, Java, and C# can be traced back to Simula while Smalltalk inspired Ruby. There is a distinct camp of "statically typed OO" (Simula and its children) and "dynamically typed OO" (Smalltalk and its children).
Yet none of this is the one true OO. All of it remains a way of describing a human mode of expression, and so is rightly subjective.
Programming Paradigms and Beyond, Shriram Krishnamurthi and Kathi Fisler:
OO is a widely-used term chock-full of ambiguity. At its foundation, OO depends on objects, which are values that combine data and procedures. The data are usually hidden (“encapsulated”) from the outside world and accessible only to those procedures. These procedures have one special argument, whose hidden data they can access, and are hence called methods, which are invoked through dynamic dispatch. This muchseems to be common to all OO languages, but beyond this they differ widely:
* Most OO languages have one distinguished object that methods depend on, but some instead have multimethods, which can dispatch on many objects at a time.
* Some OO languages have a notion of a class, which is a template for making objects. In these languages, it is vital for programmers to understand the class-object distinction, and many students struggle with it (Eckerdal & Thune, 2005). However, many languages considered OO do nothave classes. The presence or absence of classes leads to very different programming patterns.
* Most OO languages have a notion of inheritance, wherein an object can refer to some other entity to provide default behavior. However, there are huge variationsin inheritance: is the other entity a class or another (prototypical) object? Can it refer to only one entity (single-inheritance) or to many (multiple-inheritance), and if the latter, how are ambiguities resolved? Is what it refers to fixed or can it change as the program runs?
* Some OO languages have types, and the role of types in determining program behavior can be subtle and can vary quite a bit across languages.
* Even though many OO aficionados take it as a given that objects should be built atop imperative state, it is not clear that one of the creators of OO, Alan Kay, intended that: “the small scale [motivation for OOP] was to find a more flexible version of assignment, and then to try to eliminate it altogether”; “[g]enerally, we don’t want the programmer to be messing around with state” (Kay, 1993).
In general, all these variations in behavior tend to get grouped together as OO, even though they lead to significantly different language designs and corresponding behaviors, and are not even exclusive to it (e.g., functional closures also encapsulate data). Thus, a phrase like “objects-first” (sec. 6.1)can in principle mean dozens of wildly different curricular structures, though in practice it seems to refers to curricula built around objects as found in Java.
FWIW, Crystal does have compile-time method_missing. Which obviously is less powerful than the runtime variant, but it is still possible to get fairly far in many practical usages.
