Смысл ООП, очевидно, будет разным - в зависимости от того, какие цели человек ставит при анализе. Если подходить к ООП утилитарно-потребительски, то от ООП достаточно того, что перечислил Axcel: удобство проектирования библиотек, удобство создания собственных классов (и, в то же время, решение проблемы хрупкости базовых классов), удобство внесения изменений там и сям. Для этого действительно достаточно канонических текстов про абстракцию-инкапсуляцию-наследование-полиморфизм.

Мне же было интересно, во что должно вылиться ООП в структурном редакторе. В приведенной выше статье делался интересный посыл: все прочие признаки ООП вторичны по отношению к полиморфизму и могут быть обеспечены не-ООП-шными (ортогональными к ООП) средствами языка. Например, инкапсуляцию могут обеспечить модули (нэймспейсы), наследование (от которого даже отказываются некоторые ООП-языки) структур данных - расширяемые записи и т.п.

Отсюда следует, что для ООП достаточно обеспечить полиморфизм в той или иной форме (перегрузка или переопределение методов в классическом ООП, процедурный тип в чистом Oberon или что-то ещё). Выбор лучшей формы полиморфизма - важная задача при разработке структурного редактора. Возможно, что формы полиморфизма, присущие тексто-ориентированным языкам программирования, вообще следует отбросить как негодные, а нужны какие-то новые формы полиморфизма, соответствующие специфике структурного редактора.

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