Comments 5
А как со скоростью языка Delight? Какой он по скорости в сравнении C++, C# и Rust?
Нет, это не КОП. В данной статье нет ни одной особенности языка, которую можно было бы отнести именно к компонентному программированию. Нам демонстрируют обычное ООП, основанное на классах, из которого убрано явное наследование и добавлено чуть-чуть сахара для поддержки композиции. В точности та же мешанина из кода и данных, что и в C++, Java и т.д…
Реальное КОП — Oberon, Component Pascal, Go. Построенный на композиции Go прекрасно обходится и без классов, и без [shared] с [virtual], и без циклических зависимостей…
P.S. Из популярных языков проблема ромбовидного наследования есть только в C++. Большинство же прочих ООП-языков, имеет интерфейсы, реализующие полиморфизм без наследования и без ромбов.
P.P.S. Использовать nextFn для вызова предшествующего в цепочке наследования метода — это, мягко говоря, странно. И, да: наследование в языке есть — неявное, в виде цепочек виртуальных функций.
Реальное КОП — Oberon, Component Pascal, Go. Построенный на композиции Go прекрасно обходится и без классов, и без [shared] с [virtual], и без циклических зависимостей…
P.S. Из популярных языков проблема ромбовидного наследования есть только в C++. Большинство же прочих ООП-языков, имеет интерфейсы, реализующие полиморфизм без наследования и без ромбов.
P.P.S. Использовать nextFn для вызова предшествующего в цепочке наследования метода — это, мягко говоря, странно. И, да: наследование в языке есть — неявное, в виде цепочек виртуальных функций.
Нам демонстрируют обычное ООП, основанное на классах
В ООП перегрузка функций возможна только на разных уровнях иерархии, в Delight перегрузка функций возможна на одном уровне иерархии — такого поведения невозможно добиться в ООП. Таким образом, финальная класс-сущность в Delight может просто состоять из списка классов-компонентов, что вполне соответствует КОП подходу.
Построенный на композиции Go прекрасно обходится и без классов, и без [shared] с [virtual], и без циклических зависимостей…
Go использует ключевое слово interface — которое обозначает что все функции в этом интерфейсе — виртуальные [virtual]. И да, в Go нет [shared], но попробуйте в Go реализовать примеры из статьи, где это [shared] используется.
Из популярных языков проблема ромбовидного наследования есть только в C++.
Проблема ромбовидного наследования возникает при множественном наследовании (из популярных языков, такую концепцию поддерживают Perl, Python и C++). Большинство современных языков, из-за сложностей отказались от множественного наследования, используя при этом одиночное наследование + наследование интерфейсов. В Delight же используется множественное наследование, но без тех проблем которые за ним стоят.
Использовать nextFn для вызова предшествующего в цепочке наследования метода
Именно следующего. Даже в ООП, первой будет вызвана функция, которая стоит выше по иерархии, а последней — декларация.
Насчёт "проблемы ромбовидного наследования только в С++" — это неправда.
Как минимум, в питоне они (и ромбы, и проблемы) тоже возникают.
Sign up to leave a comment.
Композиция вместо наследования в языке программирования Delight