Здравствуйте, WolfHound, Вы писали:

WH>

WH>monsters
WH>    .FindNearMonsters(bullet) // отсекаем большую часть живности используя что-то типа quadmap.
WH>    .FlatMap(monster => // Находим всех монстров в которых попадает эта пуля
WH>        do
WH>        {
WH>            dist <- monster.Collide(bullet); // Collide возвращает option (он же maby)
WH>            return (dist, monster);
WH>        })
WH>    .FindBest(((oldDist, _), (newDist, _)) => newDist < oldDist) // Выбераем первого
WH>

WH>Даже если забыть про FindNearMonsters который экономит кучу времени выбор первого монстра для убивания выносит мозг на корню. Как это сделать используя реактивное программирование я не знаю.

Подождите, тут же как раз dataflow:
Есть поток монстров. Он проходит через фильтр. Потом поток раздваивается, одна часть проходит через преобразователь и фильтр, вторая остается неизменной. Потом два получившихся потока перемножаются. А потом результирующий поток сворачивается в скаляр.

Здравствуйте, Klapaucius, Вы писали:

K>Подождите, тут же как раз dataflow:
K>Есть поток монстров. Он проходит через фильтр. Потом поток раздваивается, одна часть проходит через преобразователь и фильтр, вторая остается неизменной. Потом два получившихся потока перемножаются. А потом результирующий поток сворачивается в скаляр.

Reactive programming is a programming paradigm oriented around data flows and the propagation of change.

Где тут "propagation of change"?

Вот для сравнения пример реактивного программирования
http://www.impredicative.com/ur/more/dragList.html

Здравствуйте, WolfHound, Вы писали:

WH>Где тут "propagation of change"?

Ну, так предложеный код — это ведь простой запрос без всякого изменения состояния. Поэтому и продвижения состояния нет — оно просто не нужно — одни только потоки данных.
Но, в любом случае, это никак не соотвествует моему представлению об ООП.
В ООП был бы объект — коллекция объектов и диспетчеризатор сообщений. У него бы вызывался метод Shoot(bullet), а он бы потом вызывал виртуальный метод Shoot(bullet), при этом объект-монстр при попадании в него этой переданной ему пули вызывал бы одни методы, а при промахе другие. Что-то вроде того.

>а он бы потом вызывал виртуальный метод Shoot(bullet), при этом объект-монстр при попадании...

Тут конечно "а он бы потом вызывал виртуальный метод Shoot(bullet) у все принадлежащих ему объектов, при этом..."

Здравствуйте, Klapaucius, Вы писали:

K>Ну, так предложеный код — это ведь простой запрос без всякого изменения состояния. Поэтому и продвижения состояния нет — оно просто не нужно — одни только потоки данных.
Мне что всю игру написать?

foreach (bullet in bullets)
{
    do
    {
        (_, monster) <- monsters
            .FindNearMonsters(bullet) // отсекаем большую часть живности используя что-то типа quadmap.
            .FlatMap(monster => // Находим всех монстров в которых попадает эта пуля
                    do
                    {
                            dist <- monster.Collide(bullet); // Collide возвращает option (он же maby)
                            return (dist, monster);
                    })
            .FindBest(((oldDist, _), (newDist, _)) => newDist < oldDist); // Выбераем первого
        def isDead = monster.Hit(bullet); // вот тебе изменение состояния.
        when (isDead)
            monsters.Remove(monster); // вот второе. Убираем мертвых монстров из коллекции.
    }
}

K>Но, в любом случае, это никак не соотвествует моему представлению об ООП.
K>В ООП был бы объект — коллекция объектов и диспетчеризатор сообщений.
ФВП ООПу не помеха.
Следи за руками:
Посылаем объеку monsters сообщение FindNearMonsters с параметром bullet.
Получаем объект который содержит монстров находящихся близко от пули.
Посылаем только что полученному объекту сообщение FlatMap с замыканием.
Замыкание тоже объект которому мы посылаем сообщение Appaly с параметром monster...

Но по большому счету все что нужно для ООП это именованное состояние и ссылки на функции.
Все остальное по большому счету сахар.

K>У него бы вызывался метод Shoot(bullet), а он бы потом вызывал виртуальный метод Shoot(bullet), при этом объект-монстр при попадании в него этой переданной ему пули вызывал бы одни методы, а при промахе другие. Что-то вроде того.
Пуля может попасть в несколько. А нам нужен только ближайший.

Здравствуйте, Ikemefula, Вы писали:

ANS>>>Как бы, с борландами, и с C++ и с ObjectPascal ходил Calc, если мне склероз не изменяет. С мордой на TurboVision. Как я помню исходники были маленькими.

BZ>>хуже того — они поставлялись в качестве примера ещё с tp 3.0. задолго до ООП

I>TurboVision — это ООП.

а тогда calc был написан на старой консольной библиотеке, с помощью gotoxy

Здравствуйте, WolfHound, Вы писали:

WH>Мне что всю игру написать?

Теперь между источником монстров и запросом из предыдущего сообщения добавляется еще фильтр, а к нему подводится поток результатов запроса. Ну и еще поток пуль к запросу добавился. Т.е. мы проталкиваем пули в поток и фильтруем монстров. Ну или наоборот, выбираем живых монстров, подтягивая пули со склада боеприпасов.

WH>ФВП ООПу не помеха.
WH>Следи за руками:

Ну да, в принципе можно для (почти?) любого кода расписать и ООП и ФП семантику. Т.е. "объектность" она бывает в голове и в деталях реализации, но никак не в коде.

WH>Пуля может попасть в несколько. А нам нужен только ближайший.

Это-то понятно. Имелось в виду, что они сообщением заявляют о себе, как о находящихся на линии выстрела. Ну а дальше их заявки рассматриваются и победителю высылается сообщение-смертный приговор.

Здравствуйте, Klapaucius, Вы писали:


V>>В чистом виде неудобно для большого кол-ва задач.
K>Ну, я, собственно, и спросил — чем не удобно? Ответ "тем что неудобно" мне кажется каким-то малосодержательным.

Основное неудобство — это плохоконтроллируемые потоки вычислений при их кол-ве чуть большем, чем на пару экранов + высокая вероятность гонок.
Без полноценного графического инструмента, типа как редактора схем электрических функциональных, решать на этой технологии даже задачи среднего уровня — утопия. Хотя, вполне можно использовать и без спец.инструментов в изолированном пространстве как способ "красиво" имеплементить какие-нить событийные мелочи.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Ikemefula, Вы писали:

ANS>>>>Как бы, с борландами, и с C++ и с ObjectPascal ходил Calc, если мне склероз не изменяет. С мордой на TurboVision. Как я помню исходники были маленькими.

BZ>>>хуже того — они поставлялись в качестве примера ещё с tp 3.0. задолго до ООП

I>>TurboVision — это ООП.

BZ>а тогда calc был написан на старой консольной библиотеке, с помощью gotoxy

Был, а был еще и тот, что с мордой на ТурбоВижн, про него и речь.

Здравствуйте, Ikemefula, Вы писали:

I>Был, а был еще и тот, что с мордой на ТурбоВижн, про него и речь.

речь вообще-то о том, что для написания calc не обязателен ни ФП, ни ООП

Здравствуйте, vdimas, Вы писали:

V>Основное неудобство — это плохоконтроллируемые потоки вычислений при их кол-ве чуть большем, чем на пару экранов

А чем описание dataflow на несколько экранов менее удобно, чем ООП код на несколько экранов?

V>Без полноценного графического инструмента, типа как редактора схем электрических функциональных, решать на этой технологии даже задачи среднего уровня — утопия.

Ну, если так нужен графический инструмент — это проблема чисто техническая. Визуализировать dataflow даже легче.
Кроме того, электрические схемы ведь тоже сейчас на языках программирования описывают, разве нет?

Здравствуйте, BulatZiganshin, Вы писали:

I>>Был, а был еще и тот, что с мордой на ТурбоВижн, про него и речь.

BZ>речь вообще-то о том, что для написания calc не обязателен ни ФП, ни ООП

Любая парадигма никогда не бывает обязательной.

Здравствуйте, Ikemefula, Вы писали:
I>>>Был, а был еще и тот, что с мордой на ТурбоВижн, про него и речь.

BZ>>речь вообще-то о том, что для написания calc не обязателен ни ФП, ни ООП

I>Любая парадигма никогда не бывает обязательной.

разумеется, языки-то тьюринг-полные. вот тебе захотелось доказать что calc можно сделать и на ООП, а я походя заметил что этот пример был у них ещё лет за 5 до tp 5.5

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Ikemefula, Вы писали:
I>>>>Был, а был еще и тот, что с мордой на ТурбоВижн, про него и речь.

BZ>>>речь вообще-то о том, что для написания calc не обязателен ни ФП, ни ООП

I>>Любая парадигма никогда не бывает обязательной.

BZ>разумеется, языки-то тьюринг-полные. вот тебе захотелось доказать что calc можно сделать и на ООП,

цитирую, что было

ANS>Как бы, с борландами, и с C++ и с ObjectPascal ходил Calc, если мне склероз не изменяет. С мордой на TurboVision.

>а я походя заметил что этот пример был у них ещё лет за 5 до tp 5.5

какие другие примеры были до TurboVision(в 6.0 а не 5.5 кстати) это уже дело десятое.
Калькулятор на TurboVision был очень неплох с т.з. демонстрации ООП.

Здравствуйте, Ikemefula, Вы писали:

ANS>>Как бы, с борландами, и с C++ и с ObjectPascal ходил Calc, если мне склероз не изменяет. С мордой на TurboVision.

I>какие другие примеры были до TurboVision(в 6.0 а не 5.5 кстати) это уже дело десятое.

ну просто Владу нужен был пример, демонстрирующий преимущества ООП. а тут выясняется что оно и до ООП было в комплекте поставки, а тут его просто взяли и переписали на TV

кстати, turbo pascal with objects и object pascal — разные языки

Здравствуйте, VladD2, Вы писали:

VD>К сожалению, в голову не приходит хороших идей для демонстрации ООП-а.

Вот так-то. Смотри сюда

Автор: VladD2
Дата: 21.03.08

.

Здравствуйте, VladD2, Вы писали:

VD>Дык не повторять же реализацию ВинФормсов только для того чтобы продемонстрировать ООП? Хотя это было бы как раз весьма неплохим примером.

Винформсы это очень гадкий ООП.

Здравствуйте, WolfHound, Вы писали:

ZS>>Можно реализовать приложение для работы с результатами тестов. Тест содержит вопросы с вариантами ответов, некоторые из них правильные.
WH>Это решается в функциональном стиле гораздо лучше.

UI, да еще с длинным стейтом в функциональном стиле — лучше?

Здравствуйте, AndrewVK, Вы писали:

VD>>Дык не повторять же реализацию ВинФормсов только для того чтобы продемонстрировать ООП? Хотя это было бы как раз весьма неплохим примером.

AVK>Винформсы это очень гадкий ООП.

Но хоть какой-то. Лучше предложи альтернативу.

Здравствуйте, VladD2, Вы писали:

VD>Но хоть какой-то. Лучше предложи альтернативу.

Сапер