История изменений
Исправление monk, (текущая версия) :
Смотрел TinyCLOS. Пока не решил. И еще не понял, как подключить, чтобы один исходный файл мог использоваться для разных реализаций. Может быть, твой пример выше подскажет.
Есть такое: https://github.com/ktakashi/r7rs-clos
А еще такой вопрос, а что на счет ООП?
А зачем? Мне в Racket ООП пригодился только при использовании графического интерфейса, да и то потому что интерфейс уже на ООП.
Я понимаю, зачем ООП в языках со статической типизацией: чтобы можно было сказать List<Element> и сложить в список любых наследников Element (который в идеале просто интерфейс). Но зачем он в динамическом языке? Практически всё, что можно сделать через ООП, можно сделать через структуры и замыкания. ((on-paint element) x y) работает ничуть не хуже, чем element.on_paint(x, y). Даже лучше, потому что у конкретного элемента можно поменять поле on-paint в любой момент.
Что мне нравится в Схеме - минимализм, изящность и функциональность, которых мне так не хватает в современном программировании! Для хобби-проекта
Я для своих проектов практически отказался от ООП и макросов именно из этих соображений. ООП необходимо только если есть сложная иерархия классов и заранее неизвестно какие классы будут добавлены в дальнейшем. Для хобби-проекта это очень вряд ли.
Исходная версия monk, :
Смотрел TinyCLOS. Пока не решил. И еще не понял, как подключить, чтобы один исходный файл мог использоваться для разных реализаций. Может быть, твой пример выше подскажет.
Есть такое: https://github.com/ktakashi/r7rs-clos
А еще такой вопрос, а что на счет ООП?
А зачем? Мне в Racket ООП пригодился только при использовании графического интерфейса, да и то потому что интерфейс уже на ООП.
Я понимаю, зачем ООП в языках со статической типизацией: чтобы можно было сказать List и сложить в список любых наследников Element (который в идеале просто интерфейс). Но зачем он в динамическом языке? Практически всё, что можно сделать через ООП, можно сделать через структуры и замыкания. ((on-paint element) x y) работает ничуть не хуже, чем element.on_paint(x, y). Даже лучше, потому что у конкретного элемента можно поменять поле on-paint в любой момент.
Что мне нравится в Схеме - минимализм, изящность и функциональность, которых мне так не хватает в современном программировании! Для хобби-проекта
Я для своих проектов практически отказался от ООП и макросов именно из этих соображений. ООП необходимо только если есть сложная иерархия классов и заранее неизвестно какие классы будут добавлены в дальнейшем. Для хобби-проекта это очень вряд ли.