Кстати, ещё по поводу модулей. То, что написано в статье будет работать только в скриптовых языках. По крайней мере, я за два дня так и не придумал способа хотя бы откомпилировать command(pet) в случае использования нескольких модулей и раздельной компиляции (чтобы не было необходимости проверять принадлежность pet соответствующему классу).

Допустим, при компиляции создаётся sym-файл, чтобы можно было готовить смежные модули. Если мы захотим использовать процедуры данного модуля, то нам будет необходимо знать устройство типа (а точнее - часть устройства класса) объекта, принимаемого в качестве параметра. На первый взгляд, это не является проблемой для синтаксического анализатора, пример тому - работающий python. Но для компиляции требуется реализовать процедуру полностью, поскольку интерфейс может меняться в зависимости от того, как широко используются методы объекта-параметра. То есть, параллельно разрабатывать модули не получится, поскольку для импортёра весь импорт должен быть уже реализован. Реализация и горячая замена модулей-импортёров не пострадает.

Но при замене модуля-экспортёра автоматом заменится и его интерфейс, следовательно, его импорт во многих случаях может стать некорректным для всё тех же импортёров. А значит, такие конструкции, как MVC или CRM, станут проблематичными. Попирается инкапсуляция - а это важная составляющая для ООП, - причём, уже и в случае компиляции, и в случае интерпретации.

Если один и тот же объект передаётся в разные процедуры модуля, то он должен реализовывать несколько интерфейсов, что может порождать конфликты.