Ответ на »сообщение 1440« (Сварог)
___________________________
Могу вам только посоветовать научиться читать :))
Библиотека cells позволяет связывать обьекты в языке. Для того чтобы прочитать данные с БД драйвер конечно же нужен.
Это вот что вы будете делать с данными ПОСЛЕ того как вы прочитаете их с БД - это где вам может помочь cells.
Ближайшим аналогом cells для дельфи будет связка
TDataSet <-> TDataSource <-> Свойство DataSource визуального обьекта <-> Внутрення процедура написанная автором компонента для использования этого свойства.

Как видите драйверами для доступа к БД тут и не пахнет.
Это уже на значительно более позднем этапе.
Преимущество функционального программирования заключается в том что всю эту длинную, громоздкую цепочку которая к тому же работает только там где вы это явно предусмотрите, заменяет одна билиотека cells, которая работает с ЛЮБЫМИ ОБЬЕКТАМИ.

Надеюсь я достаточно мелко разжевал, чтобы господину Сварогу опять в этой кашице драйвера БД не привиделись :))

Ответ на »сообщение 1436« (Сергей Перовский)
___________________________

Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.
Во вторых это TAction с его onAction и onUpdate.

Как раз наоборот. В Delphi я вынужден писать обработчик OnUpdate, в котором надо присвоить значение в свойство Enabled соответствующего действия.
Вы никогда не ошибались с идентификатором действия? А с тем, что если забыть выполнить присваивавание, то компилятор даже теоретически не сможет Вас предупредупредить?
Мне это очень мешает. Функция, которую я мог бы указать для определения значения Enabled была бы намного удобнее. Да еще бы и компилятор предупреждал, что в одной из ветвей алгоритма я забыл возвратить результат (присвоить Result).
То же самое с вычисляемыми полями. OnCalcFields провоцирует на ошибки. Даже язык формул Excel в ряде случаев оказывается намного удобнее, чем вычисляемые поля в Delphi.

Честнслово, сообщения Jack Of Shadows из мира функционального программирования я читаю прямо как книги Мулдашева о Шамбале. В каждом посте – сплошные чудеса!

Вот и сейчас оказалось, что существует Святой Грааль... тьфу, библиотека cells, которая способно подключить любую БД безо всяких драйверов!

Ответ на »сообщение 1436« (Сергей Перовский)
___________________________
Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.

Ошибаетесь.
Давайте рассмотрим на примере.

Прежде всего вам доступно "навешивание" функций только в точках о которых позаботился создатель компонента.
То есть это либо event handlers типа OnCLick, OnChange, которые должны быть явно предусмотрены создателем компонента. Если нет - вам не повезло.
Или же это должны быть специальные свойства (property) типа DataSource, опять же явно предусмотренные создателем. Если нет - то вам опять не повезло.

Скажем для того чтобы в editbox отображалось значение поля из таблицы - вам нужно свойство DataSource.
А вот если бы Delphi был поноценным функциональным языком, то для него можно было бы портировать вот эту вот библиотеку cells, которая дала бы вам следующие возможности.

  myEditBox1.Text := ?f: qryMyTableFirstName.Value;

ВСЕ!! Никаких DataSource от Борланд! Никаких специальных db-aware компонент! Никаких "Вам придется написать TDataSet для вашей базы данных потому что в коробке поставляются только TDataSet для odbc, оракла и парадокса".

Естественно такое вот ДЕКЛАРИРОВАНИЕ СВЯЗЕЙ не ограничивается одними только визуальными компнонентами.
Например:

  Logger.SendWarningEmail := ?f: Engine.Temperature > 150;

Или

  StatusBar.Position := ?f: FTPDownload.BytesDownloaded / FTPDownload.FileSize;

Или

  MenuItemFileSave.Enabled := ?f: CurrentFile.isDirty;

Сравните это с количеством и главное сложностью кода которое приходится писать в Дельфи, для обеспечения взаимодействия разнородных обьектов.

Ответ на »сообщение 1421« (Артем)
___________________________
Операции присваивания вас погубят!
Артем, не юродствуйте. Вы же можете вполне конструктивно вести дискуссию.
Ваш пост откровенная провокация.
Невправильное обучение может дествительно погубить в человеке программиста.
Эта мысль поддерживается всеми школами, как императивной так и фнукциональной.
Более того и методика одна и таже - оградить студента от знакомства с "лишними" "опасными" "ненужными" вещами.
Разница в частностях, в том кто и что считает "лишним" "опасным" "ненужным".

Ответ на »сообщение 1436« (Сергей Перовский)
___________________________
Прописывать формулы прямо в ObjectInspectore красиво, но ведь это все равно DesignTime, можно и метод перекрыть.

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

Впрочем, может быть я чего-то недооцениваю.
Эт точно. Чтобы оценить попробуйте использовать обычные editbox и обычный grid (не db-aware) в дельфи с каким нибудь внешним источником данных..
Сразу поймете, что если дядя (в данном случае Борланд) не предусмотрит для вас соответствующий механизм, то придется все делать самому ручками.
А библиотека cells навешивает такой механизм на ЛЮБОЙ класс, даже если он написан не вами, даже если у вас и исходников то нет.

То есть нужда в СПЕЦИАЛЬНО написанных db-aware components отпадает. И не только.
Скажем вам нужно чтобы grid показывал список обьектов из обьектной базы данных.
Оба на! db-aware controls не расчитаны на работу с обьектными БД.
ВОт и получается что вы внезапно остаетесь без удобного инструмента и у вас только один выход - делать его самому.

Библиотека cells прекрасно показывает насколько наши представления о легкости написания GUI на ОО языках надуманны и беспочвенны.
Легкость нам обеспечивают громодкие и дорогие механизмы, построенные для нас дядями с толстыми кошельками, то есть Дельфи IDE от Борланд и VS от Microsoft.
При этом механизмы эти весьма узко-специфичны. Шаг влево или вправо, и они отказываются работать, бросают вас на произвол судьбы, становятся бесполезными.

MS например доперла до этого после первой версии dotnet и во второй доделала механизм синхронизации визуальных компонент с источниками данных. Теперь этот механизм позволяет подключать не только таблицы с реляционных бах данных, но и просто списки обьектов.
Этого пришлось ждать аж целых 4 года. Но даже это усовершенствование все равно остается узкоспецифичным.
Просто потому что этот механизм работает НЕ СО ВСЕМИ классами, а только с теми о которых позаботилась MS.

Для остальных вам придется корячиться и писать специальные адаптеры.

Сравните это с теми возможностями которые дает вам одна маленькая и бесплатная библиоека cells, которую в течении нескольких месяцев разработал всего один человек.
Разве он умнее огромной армии программистов MS и Борланд ?
Нет конечно. Просто у него в руках инструмент, позволяющий делать такие чудеса.
У него в руках ФЯ.

А программисты Борланд и MS вынужденны создавать огромные, громоздкие машины, как будто сошедшие с иллюстраций к книгам Жюля Верна.

Динамическое взаимодействие разнородных обьектов, то есть как раз все эти задачи отображения и синхронизации некоего набора данных на их визуальное представление - прекрасный пример того насколько неуклюжим ялвяется императивный ОО подход для этого класса задач.

Например широко разлекламированная система ECO (бывший Bold) от Борланд - та вообще со своим набором визуальных контролов приходит. Цирк просто. Каждому обьектному OO framework - свой набор визуальных обьектов. Почему ? Ах, взаимодействие и ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ очень тяжело оказывается организовать. :))

Ответ на »сообщение 1435« (panda)
___________________________
Этот подход частично реализован в Дельфи.
Во первых это свойства объектов, за которыми могут стоять функции.
Во вторых это TAction с его onAction и onUpdate.
Прописывать формулы прямо в ObjectInspectore красиво, но ведь это все равно DesignTime, можно и метод перекрыть.
Если речь идет о синхронном присваивании текстовых значений, то такую систему я для своих проектов давно реализовал.
Впрочем, может быть я чего-то недооцениваю.

Ответ на »сообщение 1434« (Сергей Перовский)
___________________________

Ну, раз в функциональные языки приходится добавлять возможности императивного программирования, значит их авторы со мной согласны - функциональное программирования лучше не во всех случаях. Тогда вопрос - в каких?
Мне очень понравилась идея описанная здесь: »сообщение 313«
Захотелось ее даже применить в своем инструменте разработки.

Ответ на »сообщение 1429« (panda)
___________________________
Ребята, давайте жить дружно (с).
Я ничего обидного в цитируемом сообщении не вижу. И не только в Ваш адрес оно написано.
Непонимания тут и так хватает. Давайте не усугублять.

К вопросу о простых и сложных примерах: хотелось бы НЕ ПРИМЕРОВ, а корректного анализа.
Тут постоянно смешиваются темы. То обсуждаем функциональный подход, то функциональные языки. Причем без явного указания.
Получается странный диалог:
-Есть случаи, когда функциональный подход неудобен...
-Так в хаскеле можно программировать императивно!

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

Ответ на »сообщение 1427« (Сергей Перовский)
___________________________
Сборка мусора не обязательно тормозить должна. Или "подтормаживать"... В Инферно три (или четыре) механизма сборки мусора. Самый медленный (глобальный шмон) применяетсяв считанных долях процента и случаев. Для подавляющего достаточно учёта выхода их блоков различной природы и вложенности.