История изменений
Исправление wandrien, (текущая версия) :
add_tooltip(add_border(button)) != add_border(add_tooltip(button))
Так и в Си++ смена последовательности наследования даёт разный результат.
Более того. Наследование является лишь одним из способов порождения пользовательских типов.
«Заданные пользователем ЯП правила порождения типов» - это ничто иное как шаблоны.
Так что мы приходим к: AddTooltip<AddBorder<Button>>.
А ещё можно делать … И получить кнопку с интегрированным изображением.
А в этом примере вообще не очевидно, почему это нужно делать на уровне класса, а не экземпляра класса. Никакой видимой выгоды в этом нет.
В Racket активно используется для обработки событий. Чтобы наследник не мог выкинуть обязательную часть алгоритма (проверку масок и всё такое). В Java часто эмулируют двумя связанными методами.
Да, это стандартный способ решения таких ситуаций. В Си++ это будет пара из невиртуального и виртуального метода.
При этом способ «решить проблему при помощи двух простых концептов» выглядит архитектурно привлекательнее, чем «изобрести специальный сложный неочевидный концепт».
Чтобы код был прозрачным, сложные взаимодействия желательно раскладывать на общеизвестные шаблоны проектирования.
Исходная версия wandrien, :
add_tooltip(add_border(button)) != add_border(add_tooltip(button))
Так и в Си++ смена последовательности наследования даёт разный результат.
Более того. Наследование является лишь одним из способов порождения пользовательских типов.
«Заданные пользователем ЯП правила порождения типов» - это ничто иное как шаблоны.
Так что мы приходим к: AddTooltip<AddBorder<Button>>.
А ещё можно делать … И получить кнопку с интегрированным изображением.
А в этом примере вообще не очевидно, почему это нужно делать на уровне класса, а не экземпляра класса. Никакой видимой выгоды в этом нет.
В Racket активно используется для обработки событий. Чтобы наследник не мог выкинуть обязательную часть алгоритма (проверку масок и всё такое). В Java часто эмулируют двумя связанными методами.
Да, это стандартный способ решения таких ситуаций. В Си++, например, это будет пара из невиртуального и виртуального метода.
При этом способ «решить проблему при помощи двух простых концептов» выглядит архитектурно привлекательнее, чем «изобрести специальный сложный неочевидный концепт».
Чтобы код был прозрачным, сложные взаимодействия желательно раскладывать на общеизвестные шаблоны проектирования.