G>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
А как же пример Пола Грехема про аккумулятор? Где как раз у него в замыкании этот счётчик и содержится
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>В своей статье Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией (на то оно и функционально ). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность
VD>Статью пока не читал, но с твоих слов выглядит что статья очередной бред.
Как-то даже отвечать особо на такое не хочется...
Но коли начал
VD>Такое ощущение что в функциональной программе не может быть объектов.
Ты программируешь основываясь на ощущениях?
ФП и ООП не противопоставляются и могут существовать, есть же и окамл и клос в лиспе и ещё много чего.
Только вот объекты в данном случае получаются зачастую излишни и задача декомпозируется без них.
Gaperton wrote: >Объект характеризуется наличием mutable state... > <skipped> > Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
??? http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html#%_sec_3.1.1
Gaperton wrote: > Функциональщина или не функциональщина тут не причем. Объект > характеризуется наличием *изменяемого состояния*, и абстрактным > интерфейсом доступа, т.е. состояние "спрятано".
Вообще говоря, это необязательно. Никто не мешает делать объекты
иммутабельными, мутирующие функции просто будут возвращать новые объекты
(как со строками в .NET/Java).
Здравствуйте, Курилка, Вы писали:
G>>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
К>А как же пример Пола Грехема про аккумулятор? Где как раз у него в замыкании этот счётчик и содержится
Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.
G>Функциональщина или не функциональщина тут не причем. Объект характеризуется наличием изменяемого состояния, и абстрактным интерфейсом доступа, т.е. состояние "спрятано". В этом суть понятия "объект", а не в том, что там является "черным" или "белым" ящиком. Когда ты получаешь параметром замыкание — ты не сможешь отличить его от обыкновенной функции, как не старайся. Суть лексического замыкания состоит в том, что "замкнутый" параметр не может меняться, а результат является функцией.
Влад уже привел пример когда у объекта нет изменяемого состояния.
G>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда.
Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:
(define x 0)
(define (f) (lambda (y) (+ x y)))
(display ((f) 3))
(display "\n")
(set! x 10)
(display ((f) 3))
(display "\n")
Выведет
3
13
Развить из этого полноценные объекты несложно. (В CLisp они вроде так и делаются)
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> Функциональщина или не функциональщина тут не причем. Объект >> характеризуется наличием *изменяемого состояния*, и абстрактным >> интерфейсом доступа, т.е. состояние "спрятано". C>Вообще говоря, это необязательно. Никто не мешает делать объекты C>иммутабельными, мутирующие функции просто будут возвращать новые объекты C>(как со строками в .NET/Java).
Мешает. Попробуй на таких объектах построить систему, увидишь. На таких "объектах" ты не получишь главного — не сможешь сделать декомпозицию системы. Просто попробуй, это проще, чем объяснить. Сделай систему с кольцевой ссылкой, и посмотри.
Здравствуйте, FR, Вы писали:
G>>Это запросто. Только контекст замыкания не может изменяться, так что нам пофиг, есть замыкание в параметрах, или его нет. Это совершенно все равно. Другое дело, что параметром может припереть функция высшего порядка, которая возвращает функцию высшего порядка, которая... потом будет передана параметром в другую функцию высшего порядка. И так несколько раз.
FR>Изменятся не может но тянуть вызовов и ссылок может не меньше чем объект.
Это не имеет значения, так как тебе не надо отслеживать изменение состояния — вся сложность в последнем. Лексическое замыкание, а именно оно у нас присутствует в ФЯ, не отличимо по своим свойствам от простой "чистой" функции.
FR>>>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния. G>>Ну конечно. А приватные переменные "состояния" не указывают на другие объекты? Глядя на публичный интерфейс ты их не видишь, а по ним, возможно, будут запущены вызовы. Вот тебе и связность.
FR>Это не связность, а граф вызовов
Это связность, она родимая . Посредством чего она достигается, и как ты ее назовешь — совершенно не важно.
Здравствуйте, Programmierer AG, Вы писали:
PA>Gaperton wrote: >>Объект характеризуется наличием mutable state... >> <skipped> >> Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изоюразишь никогда. PA>???
Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.
Здравствуйте, Gaperton, Вы писали:
G>Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.
Возможность изменять переменную определенную локально есть и в ML и в OCaml. Нет такой возможности в чистых языках.
G>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.
Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Gaperton, Вы писали:
G>>Я имел в виду лексические замыкания. Динамические замыкания — это не ФП. Как и Схема, которую ты привел — полноценный императивный язык.
Q>Возможность изменять переменную определенную локально есть и в ML и в OCaml. Нет такой возможности в чистых языках.
В Эрланге, о котором и говорил автор статьи, такой возможности нет. Эта возможность — императивна, это не ФП, глупо ее противопоставлять ОО, и не важно, присутствует она в языках или нет. Что вы мне все тут доказать хотите?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
G>>Функциональщина или не функциональщина тут не причем. Объект характеризуется наличием изменяемого состояния, и абстрактным интерфейсом доступа, т.е. состояние "спрятано". В этом суть понятия "объект", а не в том, что там является "черным" или "белым" ящиком. Когда ты получаешь параметром замыкание — ты не сможешь отличить его от обыкновенной функции, как не старайся. Суть лексического замыкания состоит в том, что "замкнутый" параметр не может меняться, а результат является функцией.
FR>Тут Re[5]: ФП против ООП
Влад уже привел пример когда у объекта нет изменяемого состояния.
Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.
Господи, объясните ему кто-нибудь.
G>>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изобразишь никогда.
FR>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код:
ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.
Здравствуйте, Курилка, Вы писали:
G>>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.
К>Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.
В замыкании может быть статическое или динамическое связывание. При статическом всегда захватывается значение переменных в момент определения замыкания, при динамическом связывание происходит в момент использования. Тут пример динамического связывания на схеме
Влад уже привел пример когда у объекта нет изменяемого состояния.
G>Чего тут не понятного. Это не объект. На таких "объектах" ты не сделаешь объектную декомпозицию, у тебя ссылки поплывут сразу. Попробуй посмотреть, что произойдет с кольцевыми ссылками при попытке "изменить" состояние такого объекта — у него нет identity.
G>Господи, объясните ему кто-нибудь.
Лучше дай правильное по твоему определение объекта.
G>>>Тот факт, что ты можешь изобразить замыкание на классах, равным счетом ничего не меняет — это частный случай. Класс на замыканиях ты не изобразишь никогда.
FR>>Запросто изображу, если язык использует динамическое связывание в замыкании, например в схеме такой код: G>ЛЕКСИЧЕСКИЕ замыкания. Динамические — это НЕ ФП. Мы тут статью обсуждаем, или языками чешем? Нет в Эрланге диамических замыканий.
Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
G>>>Это т.н. "динамическое" замыкание, кроме как в лиспе в "наших" языках не присутствует. Эта штука — да, объект. Но только к ФП никакого отношения не имеет.
К>>Ммм, можно про "динамическое" поподробней, ссылочку или ещё что — что-то не помню подобных классификации замыканий.
FR>В замыкании может быть статическое или динамическое связывание. При статическом всегда захватывается значение переменных в момент определения замыкания, при динамическом связывание происходит в момент использования. Тут пример динамического связывания на схеме
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Ну тема же не про эрланг а "ФП против ООП", а ты ее сузил до "чистый ФП против ООП"
К>Ну вообще-то началось всё как раз с эрланга, про который Ярив писал
Здравствуйте, Курилка, Вы писали:
FR>>В замыкании может быть статическое или динамическое связывание. При статическом всегда захватывается значение переменных в момент определения замыкания, при динамическом связывание происходит в момент использования. Тут пример динамического связывания на схеме
Gaperton wrote: > C>Вообще говоря, это необязательно. Никто не мешает делать объекты > C>иммутабельными, мутирующие функции просто будут возвращать новые объекты > C>(как со строками в .NET/Java). > Мешает. Попробуй на таких объектах построить систему, увидишь. На таких > "объектах" ты не получишь главного — не сможешь сделать декомпозицию > системы. Просто попробуй, это проще, чем объяснить. Сделай систему с > кольцевой ссылкой, и посмотри.
Можно и с кольцевой. Громоздно только получается...
class B;
class A
{
friend class B;
int var;
B *b;
public:
A* mutate_something() const
{
A *a=new A;
a->var=var*2;
a->b=new B(*b);
b->a=a;
return a;
}
};
class B
{
friend class A;
A *a;
public:
//...
}
Громоздко, но возможно. У этого подхода есть огромный минус — гигантский
оверхед. Поэтому у себя я ввел понятие "контекстных указателей" — их
значение зависит от контекста в котором они разыменовываются.
Фактически, это позволяет работать с графом в функциональном стиле — то
есть измененный объект попадает в свой собственный виртуальный граф,
который не влияет на старый. У меня это еще завязано на транзакции —
одна из копий графа считается "авторитетной" и можно в нее "коммитить"
виртуальные графы.
Не знаю как проще объяснить — вероятно придется писать статью
). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность 
