У замыкания эффективно есть только один метод: вызов. Естественно, можно эмулировать множественность методов и даже их динамическое добавление, но у объектов методы принципиально отделены.
Замыкание — это поведение с прицепленным снизу состоянием. Объект — это состояние с навешенным сверху поведением.
Я это к тому, что новые замыкания, оперирующие этим замкнутым значением, можно добавить только внутри той let-формы. Вне её уже никак. Единственный вариант обхода — рефлексия: или самим лезть в кишки замыкания, или попросить отдать замкнутую переменную добровольно.
Объекты не подразумевают априори вот такой замкнутости, которую только рефлексией и разрулить можно. У объектов методы отделены от данных, они существуют в единственном экземляре, тогда как замыкания — это как раз экземпляры метода, прибиваемые гвоздями к конкретным данным в их замкнутом окружении.
Ах да, ещё один аспект: типизация. На объекты и методы типы как-то удобнее накладываются, чем попытки как-то отличить (lambda (n) (set! closed-n n)) от другой (lambda (n) (set! closed-n (+ closed-n n))), относящейся к другому <<объекту>>.
тогда как замыкания — это как раз экземпляры метода, прибиваемые гвоздями к конкретным данным в их замкнутом окружении
Экземпляры метода могут и сами быть данными, а непосредственно данные могут передаваться в эти методы внутри замыкания как параметры. Тогда достаточно иметь внутри замыкания только одну функцию - диспетчер, который применяет методы из динамически формируемого списка. Собственно, примерно так устроены все объектные системы на замыканиях.
Функция возвращающая функцию является конструктором объекта.
Возвращаемая функция может называться интерфейсом объекта управляемым через параметры этой функции.
Наследования нет и не нужно наверно. Для доступа к существующему функционалу можно в параметры функции конструктора передать нужные интерфейсы, которые будут доступны возвращаемому интерфейсу.
И как в «настоящем» ООП, не вызываешь методы, а посылаешь объекту сообщение. Например название метода объекта в первом параметре функции интерфейса.
Ах да, ещё один аспект: типизация. На объекты и методы типы как-то удобнее накладываются, чем попытки как-то отличить (lambda (n) (set! closed-n n)) от другой (lambda (n) (set! closed-n (+ closed-n n))), относящейся к другому <<объекту>>.
Как будто в статически типизированном языке что-то мешает использовать замыкания.
Я это к тому, что новые замыкания, оперирующие этим замкнутым значением, можно добавить только внутри той let-формы.
Это вполне нормально, что добавляемые извне методы не должны ничего знать о внутреннем устройстве, а оперировать с объектом через уже имеющийся интерфейс, поэтому не вижу проблемы.
Потому что мне концептуально не нравится, что какие-то два (Number → Number) на самом деле выполняют совершенно различные действия над различными объектами. Для чистых функций да, параметры можно считать интерфейсом. Но объекты это всё же состояние, неплохо бы тип этого состояния тоже включать в интерфейс.
Объекты на замыканиях как-то ближе к прототипной модели ООП. Не то, чтобы это что-то плохое, но типизации можно сказать пока.
Какая разница между захватом объектов(ссылок на объекты) из лексического контекста и объектом? Даже не знаю, с чего начать...
Что у них общего, кроме того, что замыкание(по крайней мере в некоторых языках) то же является объектом и того, что с помощью замыканий можно неэффективно накостылить любые структуры данных?
Cell — вот это отличает данную пару get() и set() от других. Это не просто функции, возвращающие int, это методы интерфейса Cell, однозначно как-то с ним связанные. Тогда как замыкания, возвращающие int — это просто замыкания, возвращающие int.
Что это такое?
Одни методы почему-то замыкают в себе данные, а другие вынуждены принимать как аргумент набор замыканий, с помощью которых до этих данных можно добраться. Можно сделать так, чтобы они замыкали этот набор в себе тоже и выглядели как «примитивные» методы, но всё равно как-то некрасиво выходит.