The down-side to replacment, the issue noted by advocates of the alternative, is that replacement semantics are in direct conflict with the notion of substitutability.
There is no guarantee that the child class will do anything even remotely similar to the code in the parent class. A child class could, for example, decide to compute logarithms in response to the square root message.
Other objects that depend upon the behavior described by the parent class may then fail when they are instead used with an instance of the child class. For this reason, great havoc can ensue if the programmer is not careful with replacements.
Of course, depending upon the skill and good will of your programmers makes some people nervous. And so some languages have tried to find ways to overcome this difficulty. The most creative solutions are not, however, found in the languages we are considering in this book, and so we will not discuss them here.