Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC> Из-за чего им сложно представить объект как собственно "объект" а не как нечто конкретное.
:super: Мне понравилось, сам вдруг задумался, а что значит объект для меня лично? Фиг его знает :???:
AC> Во вторых необходимо разработать программный инструмент, который бы облегчил программисту перенос создаваемой им программы из голов в компьютер, и наоборот.
Да пора, давно пора развернуться и обратить внимание — что же там творится в голове у этих программистов!!!
:beer:
Революция в програмировании придет совсем с другой стороны. Со стороны "не ждали".
То что сейчас обсуждается как языковые фичи , обсуждалось и 30 лет назад. Никаких революций с тех пор не случилось.
А вот технологии автоматической оптимизации начинают интенсивно эволюционировать , и на них есть колосальный рыночный спрос. Так вот оптимизирующие компиляторы нового поколения изменят индустрию до неузнаваемости.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, minorlogic, Вы писали: M>Революция в програмировании придет совсем с другой стороны. Со стороны "не ждали".
Я, за эволюцию M>А вот технологии автоматической оптимизации начинают интенсивно эволюционировать , и на них есть колосальный рыночный спрос. Так вот оптимизирующие компиляторы нового поколения изменят индустрию до неузнаваемости.
Оптимизация штука хорошая, но чтоб существенно изменить индустрию ПО... думаю это врядли.
Почему вы так считаете?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Оптимизация штука хорошая, но чтоб существенно изменить индустрию ПО... думаю это врядли. AC>Почему вы так считаете?
А вы представте себе программу написанную в декларативном стиле которая компилируется и выполняется без существенных накладных расходов. Или новые версии Java JIT которые используют все преимущества рантайм анализа? Среднестатистическое програмирование может радикально измениться.
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников?
Все будет хорошо. Надеюсь, что никаких революций не будет. Наилучшим путем развития будет взаимопроникновение парадигм, оттачивание и совершенствование языков программирования, вплоть до мелочей. Нередко именно из-за мелочей, на первый взгляд незначительных упущений в дизайне языков исходные коды программ теряют элегантность и становятся толстыми и неповоротливыми. Также нужно совершенствование сред разработки, библиотек, фреймворков и технологий. Языки, надеюсь, останутся текстовыми, но при проектировании новых языков люди будут сначала думать "а удобен ли этот язык для какого-либо визуального представления средствами IDE?".
AC>В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Ни одна проблема не решена, включая глобальные переменные, внутреннее состояние (в данном случае — в компонентах), возможности пройти по несуществующей ссылке (в данном случае это "хендл" компонента) и т.д. и т.п.
Запрет на создание циклических ссылок? А слабо сделать так, чтобы не было вообще ссылок?
Здравствуйте, AlexCab, Вы писали:
AC>Мнения, особенно замечания и конструктивная критика, приветствуются!
очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики".. получается, что человек для "игры в кубики" просто не нужен..
плюс компонентов будет много.. очень много, больше, чем кажется..
фактически при таком подходе каждый кодер будет делать свою пачку компонентов, потому всю логику реализовать в компонентах времени не хватит.. следующая парадигма вытеснит
про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет..
следовательно КОП не нужно
...coding for chaos...
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, os24ever, Вы писали: O>Ни одна проблема не решена, включая глобальные переменные,
Отсутствуют. O>внутреннее состояние (в данном случае — в компонентах),
Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании? К тому можно создавать компоненты без внутреннего состояния, но тогда это будут просто библиотеки функций. O>возможности пройти по несуществующей ссылке (в данном случае это "хендл" компонента)
Эту да, пока не удалось решить, но так как хендлы буду (предположительно) использоваться гораздо-гораздо реже, вероятность возникновения таких ошибок значительно меньше. O>и т.д. и т.п.
А по подробней?
O>Запрет на создание циклических ссылок?
Нет, можно сколько угодно создавать циклических хендлов и подключений, кроме подключений root'овских интерфейсов, они да, не могут быть циклическими(но тут очень простое правило: root'овский интерфейс подключается первым, отключается последним и остаётся подключённым всё время "жизни" компонента, т.е. сделать такое подключение циклическим в принципе не получится). O>А слабо сделать так, чтобы не было вообще ссылок?
Во первых, ссылки(хендлы), в общем-то нужны только для того, чтобы рантайм "дать знать" одному компоненту о другом, например, в случае когда необходим учёт компонентов(к примеру в оконном приложении с вкладками, компоенет управляющий вкладками должен "знать" о всех компонентах-вкладках, для чего имеет список их хендлов). Если в приложении такой возможности не требуется(например это простое приложение без динамических компонентов), то хендлы можно(и нужно) не использовать.
Во вторых, ссылки делают КОПрограммирование похожим на ООП, т.е. при переходе с ООП вам не придётся долго и нудно вникать в теорию, вы можете поначалу просто писать код, почти "как раньше".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, neFormal, Вы писали: F>очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики"..
В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие. F>получается, что человек для "игры в кубики" просто не нужен..
Это уж как разроб сочтёт нужным. Я думаю, такое будет редкостью, т.к. разработка полностью автоматической системы сложна, дорога (а потому не рентабельна), и часто вовсе не возможна. F>плюс компонентов будет много.. очень много, больше, чем кажется.. F>фактически при таком подходе каждый кодер будет делать свою пачку компонентов,
Это не страшно и, от этого никуда не деться, людям интересней сделать что-то своё, чем использовать готовое но чужое. F>потому всю логику реализовать в компонентах времени не хватит.. следующая парадигма вытеснит
Всю не надо, предполагается тесная интеграция с другими ЯП на JVM, так что можно будет например, написать часть приложения в КОП стиле, часть в ФП, часть в ООП и, разумеется использовать готовое. F>про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет..
Как и в других парадигмах, реюз компонентов очень сложен, если они для этого специально не разрабатывались. Во втором и третьем примерах, реюз выполняется при помощи наследования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
F>>очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики".. AC>В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие.
Так его постоянно допиливают на местах. Там не только же сборка из кубиков.
F>>получается, что человек для "игры в кубики" просто не нужен.. AC>Это уж как разроб сочтёт нужным. Я думаю, такое будет редкостью, т.к. разработка полностью автоматической системы сложна, дорога (а потому не рентабельна), и часто вовсе не возможна.
Я к тому, что человек, создающий кубики, за 5 минут их сможет составлять в любые конструкции.
Т.е. работодатель не будет брать сборщика.
F>>про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет.. AC>Как и в других парадигмах, реюз компонентов очень сложен, если они для этого специально не разрабатывались.
Тогда надо решать проблему реюза, иначе смысла от КОП не будет, т.к. сейчас при здравом подходе задачи делятся по сложности между разными людьми. Только реюз позволит
Даже если и возникнет необходимость в разработке новых компонентов, то во первых, их количество будет небольшим(по сравнению готовыми компонентами, использованными в приложении), во вторых, у вас(как разработчика компонента) уже будет "окружение" из готовых компонентов, т.е. вам будет на что опереться/отчего оттолкнуться(иначе говоря будет достаточно просто создать компонент связывающий в одно приложение уже готовые части).
Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..."
Работа сведётся к созданию компонентов при мало-мальски сложных задачах. Более того, оверхед от новых компонентов, вероятно, будет зашкаливать.
Ещё интересно, как будет работать система с данными, которые надо по-разному обрабатывать?
Есть, например, платежи. В первый раз система была реализована для проведения платежей, а во второй потребовалось, чтобы к платежу добавлялся рандомный бонус. В интерфейсе для указания бонуса нужно добавить галочку и счётчик процентов бонуса.
Что надо сделать средствами КОП?
AC>Во втором и третьем примерах, реюз выполняется при помощи наследования.
Тогда что не решается наследованием, что может решиться через КОП?
Здравствуйте, AlexCab, Вы писали:
AC>Мнения, особенно замечания и конструктивная критика, приветствуются!
Картинки отличные!
Текст неплохо бы через спеллчекер и/или ворд хотя бы прогнать, русская языка для автора очно сложная однако.
Содержание: поздравляю, вы заново переизобрели COM. Заметных отличий не видно.
Re[4]: Заметка: Компонентная философия и реализация
AC>>В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие. F>Так его постоянно допиливают на местах. Там не только же сборка из кубиков.
Не встречал такого где работал, видел только что "конфигурируют", но там есть COM так что может быть. F>Я к тому, что человек, создающий кубики, за 5 минут их сможет составлять в любые конструкции.
Держать такого, там, где достаточно навыка сборки из кубиков, не выгодно. F>Т.е. работодатель не будет брать сборщика.
Ему(работодателю) и не нужно брать сборщика, если "собирание из кубиков" станет достаточно простым, с ним справится и не программист(но специалист в какой-то другой области). F>Тогда надо решать проблему реюза, иначе смысла от КОП не будет, т.к. сейчас при здравом подходе задачи делятся по сложности между разными людьми.
Эта проблема решится сама, если/когда писать переиспользуемый кода станет выгодней, чему, я надеюсь, КОП сильно поспособствует. F>
F>Даже если и возникнет необходимость в разработке новых компонентов, то во первых, их количество будет небольшим(по сравнению готовыми компонентами, использованными в приложении), во вторых, у вас(как разработчика компонента) уже будет "окружение" из готовых компонентов, т.е. вам будет на что опереться/отчего оттолкнуться(иначе говоря будет достаточно просто создать компонент связывающий в одно приложение уже готовые части).
F>Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..."
Потому же, почему большая часть кода, многих приложений, в библиотеках и, достаточно просто написать "склеивающий" код. В КОП это будет ещё проще, так как часть приложения(возможно даже очень значительную) получится создать методом "сборки из кубиков". F>Работа сведётся к созданию компонентов при мало-мальски сложных задачах.
В сложных нет, но в уникальных, пожалуй да. F>Более того, оверхед от новых компонентов, вероятно, будет зашкаливать.
Т.е.? F>Ещё интересно, как будет работать система с данными, которые надо по-разному обрабатывать? F>Есть, например, платежи. В первый раз система была реализована для проведения платежей, а во второй потребовалось, чтобы к платежу добавлялся рандомный бонус. В интерфейсе для указания бонуса нужно добавить галочку и счётчик процентов бонуса. F>Что надо сделать средствами КОП? Плохой способ:
В бухгалтерском фреймворке просто должно быть два компонента, обычный платёж и платёж с бонусом соответственно. Счётчик размещается БД, в записи плательщика. Хороший способ:
В фрейворке должен быть набор компонентов:
форма — на которой другие компоненты размещают свои пользовательские интерфейсы(поля, кнопки etc.),
стандартный платёж — включающий всегда востребованный минимум возможностей,
бонус — компонент вычисляющий бонус, он создаётся(и добавляет элементы своего UI на форму) если у плательщика собственно есть бонус,
штраф — аналогично предыдущему,
и т.п.
Когда оператор нажимает кнопку "платёж", компонент(обрабатывающий эту кнопку) выполняет скрипт(написанный прикладным программистом), и создаёт к-форму и к-стандартный платёж. Далее когда оператор вводит данные плательщика, к-стандартный платёж обращается к к-БД, за подтверждением и доп. информацией плательщика. Если у плательщика есть бонус, к-стандартный платёж создаёт к-бонус, который добавляет элементы своего UI на форму. Когда оператор нажимает кнопку "проплатить", к-стандартный платёж передаёт данные платежа(перед отправкой в БД) к-бонусу, который вносит в них требуемые изменения. Если вы пишите что то своё, не используя фреймворк или если нет подходящего компонента:
Тут да, приёдётся писать "обычным"(как в ООП) способом самим или заказывать компонент у стороннего производителя. AC>>Во втором и третьем примерах, реюз выполняется при помощи наследования. F>Тогда что не решается наследованием, что может решиться через КОП?
Всё, для чего есть уже реализованный набор компонентов. А наследование используется для реюза при разработке самих компонентов.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, D. Mon, Вы писали: DM>Содержание: поздравляю, вы заново переизобрели COM. Заметных отличий не видно.
Да, это похоже на COM. Пожалуй, самое главное отличие в том что COM это надстройка над ООП. Здесь же компоненты как-бы на одном уровне с объектами("Компоненты, это объекты с упорядоченными связями!"). Ну и ещё много разных мелких плюшек.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
O>>Ни одна проблема не решена, включая глобальные переменные, AC>Отсутствуют. O>>внутреннее состояние (в данном случае — в компонентах), AC>Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании?
Так это и есть глобальные переменные
AC>К тому можно создавать компоненты без внутреннего состояния, но тогда это будут просто библиотеки функций.
Вот их и надо создавать.
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Да, это похоже на COM. Пожалуй, самое главное отличие в том что COM это надстройка над ООП. Здесь же компоненты как-бы на одном уровне с объектами("Компоненты, это объекты с упорядоченными связями!"). Ну и ещё много разных мелких плюшек.
Да, плюшки приятные имеются. Но в целом складывается впечатление, что разработка в такой манере только усложнится. Потому что на каждый чих нужен новый компонент, надежда иметь исчерпывающую их библиотеку не оправдается (пример с бонусами выше это показывает). А реализация компонентов требует довольно много усилий по соблюдению их правильного поведения — все эти реверансы с подключениями, рестартами, версионностью. Если это все честно реализовывать для всех компонентов, это вероятно может повысить качество кода, но ценой бОльших усилий по его написанию. А вот тут нас и ждет провал, большинство программистов выберут более простой путь, где основную логику можно описать прямо и не задумываясь о компонентных протоколах.
Когда COM появился, на него же очень похожие надежды возлагали. Но оказалось, что очень уж муторно так писать. Как его эволюция позже возник .net, например.
Здравствуйте, minorlogic, Вы писали:
M>А вы представте себе программу написанную в декларативном стиле которая компилируется и выполняется без существенных накладных расходов. Или новые версии Java JIT которые используют все преимущества рантайм анализа? Среднестатистическое програмирование может радикально измениться.
Пока что все с точностью до наоборот. Ява/дотнет на телефонах статически прекомпилируется, что дает значительный выигрышь в производительности.
С ДСЛ-ями согласен, но универсальные оптимизаторы тут совсем не причем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Заметка: Компонентная философия и реализация
O>>>внутреннее состояние (в данном случае — в компонентах), AC>>Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании? O>Так это и есть глобальные переменные
Какие ж они глобальные? Это конечно не чистое ФП, когда "состояние программы это состояние всех функций", но чтобы один компонент смог изменить другой он должен: 1) иметь соответствующий интерфейс; 2) в принципе "знать"(знать имя или как-то получить хендл) о другом. К тому же другой компонент может и не разрешить себя изменять.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Ему(работодателю) и не нужно брать сборщика, если "собирание из кубиков" станет достаточно простым, с ним справится и не программист(но специалист в какой-то другой области).
Я вижу, что КОП нацелен на упрощение сборки при постоянной необходимости создания компонентов. Т.е. всегда нужен программист и никогда сборщик.
Разве не так?
AC>Эта проблема решится сама, если/когда писать переиспользуемый кода станет выгодней, чему, я надеюсь, КОП сильно поспособствует.
Вот примеров хотелось бы.
Желательно в коде
F>>Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..." AC>Потому же, почему большая часть кода, многих приложений, в библиотеках и, достаточно просто написать "склеивающий" код. В КОП это будет ещё проще, так как часть приложения(возможно даже очень значительную) получится создать методом "сборки из кубиков".
Видится мне, что в этом случае компоненты будут очень маленькими. Тогда оверхед будет на их связи друг с другом.
F>>Более того, оверхед от новых компонентов, вероятно, будет зашкаливать. AC>Т.е.?
Чтобы переделать на свой лад, надо будет сделать либо с нуля, либо отнаследоваться. В первом случае оверхед по объёму, во втором оверхед либо по зависимостям(если код не будет дублироваться в компоненте), либо по размеру компонента(если код будет копироваться в компонент).
AC>Хороший способ:
компоненты довольно мелкие
...coding for chaos...
Re[4]: Заметка: Компонентная философия и реализация
DM>Да, плюшки приятные имеются. Но в целом складывается впечатление, что разработка в такой манере только усложнится. Потому что на каждый чих нужен новый компонент,
Не нужен, вы же не создаёте объект на каждый чих, например во втором примере заметки есть компонент "Math", это просто библиотека математических функций и констант. "Компонент на каждый чих" нужен (и то не всегда, если есть обратная связь с пользователями можно "развивать" фреймворк по не многу, по мере необходимости) только если вы создаёте библиотеку компонентов(фреймворк) для некоторой предметной области, которую будут использовать прикладные программисты не умеющие сами создавать компоненты. DM>надежда иметь исчерпывающую их библиотеку не оправдается
Исчерпывающую не нужно, нужно достаточную в рамках предметной области. DM>(пример с бонусами выше это показывает).
Как это можно реализовать проще? DM>А реализация компонентов требует довольно много усилий по соблюдению их правильного поведения — все эти реверансы с подключениями,
Это, думаю, можно будет засахарить, приблизив по сложности к ООП. DM>рестартами,
Это нужно только если вы пишите приложение с высокой степенью отказоустойчивости. DM>версионностью.
Как и в COM, имеют значения только версии интерфейсов. DM>Если это все честно реализовывать для всех компонентов, это вероятно может повысить качество кода, но ценой бОльших усилий по его написанию.
Абсолютно не обязательно это реализовывать для всех компонентов, только для тех которые этого требуют. DM>А вот тут нас и ждет провал, большинство программистов выберут более простой путь, где основную логику можно описать прямо и не задумываясь о компонентных протоколах.
Поинт в том, чтоб программисты (в идеале) выбрали ещё более простой путь, где вообще не нужно ничего писать.
DM>Когда COM появился, на него же очень похожие надежды возлагали. Но оказалось, что очень уж муторно так писать. Как его эволюция позже возник .net, например.
COM был (и есть) слишком сложен и "массивен". .NET сделали проще, и он стал более распространённым. Что если сделать ещё более простую технологию?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, VladD2, Вы писали: VD>Зачем переизобретать КОП ума не приложу?
Не переизобретать, а доводить до ума. VD>Пассажи о ДСЛ-ях вообще за гранью фола (предмет явно плохо изучен).
А по подробней? VD>Можно в двух словах описать отличия от: VD>1. COM.
Нет объектов, нет привязки к Win, сильно проще. VD>2. Win RT.
Не API. VD>3. Java.
Нет объектов, есть компоненты. VD>4. .Net.
Нет объектов, проще.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Заметка: Компонентная философия и реализация
AC>>Ему(работодателю) и не нужно брать сборщика, если "собирание из кубиков" станет достаточно простым, с ним справится и не программист(но специалист в какой-то другой области). F>Я вижу, что КОП нацелен на упрощение сборки при постоянной необходимости создания компонентов. Т.е. всегда нужен программист и никогда сборщик. F>Разве не так?
Не так, без постоянной необходимости создания компонентов, программист нужен только на этапе разработки фреймворка и периодически для поддержки(вам же, как пользователю ПО и (от части) библиотек не нужен постоянно программист). AC>>Эта проблема решится сама, если/когда писать переиспользуемый кода станет выгодней, чему, я надеюсь, КОП сильно поспособствует. F>Вот примеров хотелось бы.
Например, ООП, на хоть сколько-то сложных задачах выгодней ПП(не в последнюю очередь за счёт более простого реюза), и потому сегодня сильно потеснило его там. F>Желательно в коде
Будет, но позже. AC>>Потому же, почему большая часть кода, многих приложений, в библиотеках и, достаточно просто написать "склеивающий" код. В КОП это будет ещё проще, так как часть приложения(возможно даже очень значительную) получится создать методом "сборки из кубиков". F>Видится мне, что в этом случае компоненты будут очень маленькими.
Так и задумано(это не COM). По идее компоненты должны быть такими же или чуть больше, чем ООП-объекты. F>Тогда оверхед будет на их связи друг с другом.
Как раз таки, за счёт упорядоченности и управляемости связей компонентов, программы в целом станут гораздо более простыми и надёжными. F>Чтобы переделать на свой лад, надо будет сделать либо с нуля, либо отнаследоваться.
Так же можно сложить сборку из более мелких компонентов(если таковые есть), или написать компонент-адаптер, реализующий то, чего вам не хватает и, скрывающий то, что лишнее. F>В первом случае оверхед по объёму,
Но, в целом (по идее) это будет требоваться гораздо реже, чем в ООП. F>во втором оверхед либо по зависимостям(если код не будет дублироваться в компоненте), F>либо по размеру компонента(если код будет копироваться в компонент).
Код, при наследовании будет копироваться (как бы, сточки зрения программиста). А проблему размера решит оптимизирующий компилятор.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
F>>Я вижу, что КОП нацелен на упрощение сборки при постоянной необходимости создания компонентов. Т.е. всегда нужен программист и никогда сборщик. F>>Разве не так? AC>Не так, без постоянной необходимости создания компонентов, программист нужен только на этапе разработки фреймворка и периодически для поддержки(вам же, как пользователю ПО и (от части) библиотек не нужен постоянно программист).
Программист нужен для реализации логики, т.к. из кубиков все варианты не соберёшь(нет, не соберёшь. инфа 146%).
AC>Так и задумано(это не COM). По идее компоненты должны быть такими же или чуть больше, чем ООП-объекты.
Получается при таком небольшом размере это переименование "объектов" в "компоненты"?
AC>Так же можно сложить сборку из более мелких компонентов(если таковые есть), или написать компонент-адаптер, реализующий то, чего вам не хватает и, скрывающий то, что лишнее.
Опять требуется программист, а не сборщик.
Плюс отличия от COM незначительны.
...coding for chaos...
Re[8]: Заметка: Компонентная философия и реализация
AC>>Не так, без постоянной необходимости создания компонентов, программист* нужен только на этапе разработки фреймворка и периодически для поддержки(вам же, как пользователю ПО и (от части) библиотек не нужен постоянно программист).
*Точнее, программист умеющий создавать компоненты. F>Программист нужен для реализации логики,
А для реализации логики уже нужен прикладной программист, в роли которого может быть и сам пользователь ОП. F>т.к. из кубиков все варианты не соберёшь(нет, не соберёшь. инфа 146%).
Почему не соберёшь? И зачем все варианты?
К тому же, например, можно сделать "кубик" интерпретирующий некоторый, специфический ЯП для описания логики, и возможно, управляющий другими "кубиками". AC>>Так и задумано(это не COM). По идее компоненты должны быть такими же или чуть больше, чем ООП-объекты. F>Получается при таком небольшом размере это переименование "объектов" в "компоненты"? Ну, по большому счёту, да. AC>>Так же можно сложить сборку из более мелких компонентов(если таковые есть), или написать компонент-адаптер, реализующий то, чего вам не хватает и, скрывающий то, что лишнее. F>Опять требуется программист, а не сборщик.
Для написания адаптера, да, но это как вариант, а сложить сборку пользователи могут и сами.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Абсолютно не обязательно это реализовывать для всех компонентов, только для тех которые этого требуют.
Тогда и преимуществ никаких по сравнению с СОМом не будет.
DM>>А вот тут нас и ждет провал, большинство программистов выберут более простой путь, где основную логику можно описать прямо и не задумываясь о компонентных протоколах. AC>Поинт в том, чтоб программисты (в идеале) выбрали ещё более простой путь, где вообще не нужно ничего писать.
Вот только предлагаемый тут подход такого решения не дает. Разнообразие задач всегда будет опережать разнообразие доступных компонентов, все время придется либо их дописывать, либо писать логику в обычном некомпонентном коде.
DM>>Когда COM появился, на него же очень похожие надежды возлагали. Но оказалось, что очень уж муторно так писать. Как его эволюция позже возник .net, например. AC>COM был (и есть) слишком сложен и "массивен". .NET сделали проще, и он стал более распространённым. Что если сделать ещё более простую технологию?
Ну так предлагаемая здесь ничуть не проще СОМ. И явно сложнее .NET.
Re[6]: Заметка: Компонентная философия и реализация
AC>>Абсолютно не обязательно это реализовывать для всех компонентов, только для тех которые этого требуют. DM>Тогда и преимуществ никаких по сравнению с СОМом не будет.
Из преимуществ над COM'ом как минимум меньшая сложность(за счёт отсутствия ООП-прослойки) и не привязанноасть к Win. AC>>Поинт в том, чтоб программисты (в идеале) выбрали ещё более простой путь, где вообще не нужно ничего писать. DM>Вот только предлагаемый тут подход такого решения не дает.
Сразу, конечно же нет, но со временем, когда этот подход станет достаточно распространённым, будет выработана методология, и накопится достаточно много библиотек компонентов... DM>Разнообразие задач всегда будет опережать разнообразие доступных компонентов, все время придется либо их дописывать, либо писать логику в обычном некомпонентном коде.
И что в это страшного? Это работа для квалифицированных специалистов.
Просто этот подход позволит сделать "пропасть", между программистами и пользователями, меньше, например, пользователь сможет собрать какую ни будь фичу сам или нанять стороннего разработчика для реализации, а не дожидаться когда её добавить разработчик программы. AC>>COM был (и есть) слишком сложен и "массивен". .NET сделали проще, и он стал более распространённым. Что если сделать ещё более простую технологию? DM>Ну так предлагаемая здесь ничуть не проще СОМ. И явно сложнее .NET.
Почему вы так решили?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
VD>>Зачем переизобретать КОП ума не приложу? AC>Не переизобретать, а доводить до ума.
Тогда на этом нужно было и сосредоточиться в статье. Лично я так и не нашел в ней каких-то значимых доработок.
VD>>Пассажи о ДСЛ-ях вообще за гранью фола (предмет явно плохо изучен). AC>А по подробней?
Подробнее — это надо каждое предложение разбирать, что долго.
VD>>Можно в двух словах описать отличия от: VD>>1. COM. AC>Нет объектов, нет привязки к Win, сильно проще.
В COM ничего сложного нет. Описать базу COM-м можно на одной странице, а у тебя получилось 16 мелким шрифтом.
Привязки к Винде у COM-а нет. Просто реализация встроена в винду. Ну, дык нет проблем сделать свою. И оных хватает.
По поводу "нет объектов" как-то не понял. Можно подробнее об этом?
VD>>2. Win RT. AC>Не API.
Чего? Ты уверен, что понимаешь, что такое Win RT? Win RT — это новая версия COM-а от Майкрософта. Я не говорю, о Win RT в смысле API для Виндовс. Я говорю о Win RT как о компонентной технологии.
VD>>3. Java. AC>Нет объектов, есть компоненты.
В Яве тоже есть компоненты. Что значит "нет объектов" по прежнему не понимаю. Может вопрос в определениях? Можно твое определение объекта услышать?
VD>>4. .Net. AC>Нет объектов, проще.
Проще — это когда что-то есть. Когда есть общие идеи, то говорить о простоте нет смыла.
Кстати, дотнет и ява, с точки зрения, компонентной модели практически однояйцевые близнецы. Так что не ясно почему в про яву не сказано "проще", а про дотнет "есть компоненты".
ЗЫ
Давай начнем разбираться с определений. Приведи, плиз, свои (краткие) определения понятий:
1. Компонент.
2. Объект.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Но я, признаться, как и многие предыдущие ораторы, не очень понимаю отличий от обычного ООП. Вроде как на обычном дотнете можно писать такие же компоненты, как у вас описано.
И еще такой момент. Как я понял, основным преимуществом предполагается легкость комбинирования готовых компонентов. Но вот будет ли это занятие действительно легким — большой вопрос. Основные усилия в этом вопросе будут архитектурного плана, как мне кажется — т.е. проработанность структуры и связей компонентов друг с другом. ИМХО, язык тут особого рояля не играет. Качественный набор библиотек на том же дотнете также позволит легко создавать из "кирпичей" приложения. Соответственно, интересно ваше мнение — в чем заслуга именно предлагаемого языка для создания переиспользуемого кода?
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>>>Абсолютно не обязательно это реализовывать для всех компонентов, только для тех которые этого требуют. DM>>Тогда и преимуществ никаких по сравнению с СОМом не будет. AC>Из преимуществ над COM'ом как минимум меньшая сложность(за счёт отсутствия ООП-прослойки) и не привязанноасть к Win.
На это уже Влад выше написал то же, что и я собирался.
AC>>>Поинт в том, чтоб программисты (в идеале) выбрали ещё более простой путь, где вообще не нужно ничего писать. DM>>Вот только предлагаемый тут подход такого решения не дает. AC>Сразу, конечно же нет, но со временем, когда этот подход станет достаточно распространённым, будет выработана методология, и накопится достаточно много библиотек компонентов...
В начале 90-х точно так же думали про ООП. Даже книжка была художественная на эту тему, Microserves, ужасно занудная. Там тоже были сплошь мечты "вот сейчас компонентов наделаем, останется только из них как из кубиков собирать". Но мечты не сбылись. MS удалось на этой идеологии понаделась офис и еще ряд вещей, но освободить программистов от программирования так и не вышло. Впрочем, на некотором уровне успех есть — тот же .NET столь удобен при разработке тем, что в базовой библиотеке классов уже очень много всего есть, бери да соединяй. Но необходимость описывать самому логику и создавать свои компоненты никуда не делась.
DM>>Разнообразие задач всегда будет опережать разнообразие доступных компонентов, все время придется либо их дописывать, либо писать логику в обычном некомпонентном коде. AC>И что в это страшного? Это работа для квалифицированных специалистов. AC>Просто этот подход позволит сделать "пропасть", между программистами и пользователями, меньше, например, пользователь сможет собрать какую ни будь фичу сам или нанять стороннего разработчика для реализации, а не дожидаться когда её добавить разработчик программы.
Это уже сделано в виде Visual Basic'a, особенно VBA, который в офисе, и VBScript для скриптов в системе. Они берут готовые компоненты и дают пользователю их задействовать в как бы очень простом языке. Но на деле используются не так часто, как планировалось, почему-то. Счастье так и не наступило.
Я не к тому, что ваш подход плох. Я к тому, что во многом он уже был реализован, и жизнь показала, что он не сделал ее сильно уж проще.
DM>>Ну так предлагаемая здесь ничуть не проще СОМ. И явно сложнее .NET. AC>Почему вы так решили?
Я ваше описание почитал. Часть описанного переводится в СОМ простой заменой названий, а еще часть выглядит некоторым усложнением.
Re[2]: Заметка: Компонентная философия и реализация
DM>Картинки отличные! DM>Текст неплохо бы через спеллчекер и/или ворд хотя бы прогнать, русская языка для автора очно сложная однако. DM>Содержание: поздравляю, вы заново переизобрели COM. Заметных отличий не видно.
Это не просто COM. Это философия сродни реактивному/агентному программированию, только с помощью КОП. То бишь, это парадигма над парадигмой компонент. )))
На самом деле единственно разумное зерно — это специальные связи компонент. Я когда-то назвал такое "пинами" в аналогичных рассуждениях: http://www.rsdn.ru/forum/philosophy/1676773.1
Но наличие таких "пин" позволяет совсем по-другому взглянуть на способ применения компонент, то бишь на способ построения программ. Поэтому вторая (бОльшая) часть поста — это уже просто полёт фантазии, что можно получить в придуманных автором координатах. Согласен, придумать можно много. И я бы эту часть вынес отдельно.
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Это не просто COM. Это философия сродни реактивному/агентному программированию, только с помощью КОП. То бишь, это парадигма над парадигмой компонент. ))) V>На самом деле единственно разумное зерно — это специальные связи компонент. Я когда-то назвал такое "пинами" в аналогичных рассуждениях: http://www.rsdn.ru/forum/philosophy/1676773.1
И это тоже уже реализовано в DirectShow, например. Как раз на базе СОМ. Там пины так и называются пинами. Имеют четкие интерфейсы и т.д. Есть графические среды для создания графов из таких компонентов, в том числе с генерацией кода.
Re[4]: Заметка: Компонентная философия и реализация
VD>Давай начнем разбираться с определений. Приведи, плиз, свои (краткие) определения понятий: VD>2. Объект.
Обычный ООП-объект, как например в Java. Образно его можно представить состоящим из интерфейса и семантика. Семантику, в свою очередь, можно разделить на состояние и поведение. VD>1. Компонент.
Это почти то же что объект, он также имеет состояние и поведение. Основные отличия в интерфейсе: 1) интерфейсов может быть несколько; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом.
И небольшими отличиями в поведении: после выполнения конструктора, внутри компонента, в отдельном потоке, может быть запущена функция(или несколько), что делает компоненты активными(способными делать что то самостоятельно, не дожидаясь вызовов методов).
Отличий действительно не много, но я считаю, что это хорошо с точки зрения переход с ООП на КОП.
Возвращаясь к вопросу отличий от COM, здесь есть картинка иллюстрирующая COM-объект, а вот как выглядят ООП и КОП объекты: AC>>Не переизобретать, а доводить до ума. VD>Тогда на этом нужно было и сосредоточиться в статье. Лично я так и не нашел в ней каких-то значимых доработок.
Учту. VD>>>Пассажи о ДСЛ-ях вообще за гранью фола (предмет явно плохо изучен). AC>>А по подробней? VD>Подробнее — это надо каждое предложение разбирать, что долго.
Ну хотя бы пару-тройку, самых фееричных. VD>В COM ничего сложного нет. Описать базу COM-м можно на одной странице, а у тебя получилось 16 мелким шрифтом.
Можно и в несколько предложений, только я вот 16 страниц написал, но всё равно мало кто понял(хотя это наверно потому что из меня фиговый писатель). VD>Привязки к Винде у COM-а нет. Просто реализация встроена в винду. Ну, дык нет проблем сделать свою. И оных хватает.
Ну, дык делаю , хоть и не совсем COM. VD>По поводу "нет объектов" как-то не понял. Можно подробнее об этом?
Вместо объектов компоненты, а внутри компонентов что-то типа Python'а, но без ООП(только значения и функции), с сильным уклоном в ФП. VD>Чего? Ты уверен, что понимаешь, что такое Win RT? Win RT — это новая версия COM-а от Майкрософта. Я не говорю, о Win RT в смысле API для Виндовс. Я говорю о Win RT как о компонентной технологии. Windows Runtime — API Metro-приложений, основанный на технологии COM, с заточкой под .NET. Я неправильно понял? VD>В Яве тоже есть компоненты. Что значит "нет объектов" по прежнему не понимаю. Может вопрос в определениях? Можно твое определение объекта услышать?
JavaBeans? Это просто набор правил кодирования. VD>>>4. .Net. AC>>Нет объектов, проще. VD>Проще — это когда что-то есть. Когда есть общие идеи, то говорить о простоте нет смыла.
А о простоте общих идей? VD>Кстати, дотнет и ява, с точки зрения, компонентной модели практически однояйцевые близнецы. Так что не ясно почему в про яву не сказано "проще",
Java не позиционируется как компонентный ЯП. VD>а про дотнет "есть компоненты".
Ты спрашивал про отличия.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали: ARK>Вот еще (довольно уже старый) экспериментальный язык со схожими идеями: http://www.composita.net/Composita.html
Спасибо, интересно. ARK>Но я, признаться, как и многие предыдущие ораторы, не очень понимаю отличий от обычного ООП. Отличий
не много, что, надеюсь поможет не "отпугнуть" программистов привыкших к ООП. Тут ведь не в различиях реализации дело, а в самом подходе к разработке ПО. ARK>Вроде как на обычном дотнете можно писать такие же компоненты, как у вас описано.
Даже на ассемблере можно. На асм. и в ООП стиле можно писать, но этим редко кто занимается, так как писать в среде(ЯП, IDE etc.) заточенной под ООП всяко проще и удобней. ARK>И еще такой момент. Как я понял, основным преимуществом предполагается легкость комбинирования готовых компонентов.
А так же возможность писать "самокомбинирующиеся" программы. И простота разработки/обновления самих компонентов(в идеале даже проще разработки ООП-классов). ARK>Но вот будет ли это занятие действительно легким — большой вопрос.
Ни попробуем — не узнаем ARK>Основные усилия в этом вопросе будут архитектурного плана, как мне кажется — т.е. проработанность структуры и связей компонентов друг с другом.
Можно особо и не архитектурить, а например, использовать инкрементный подход или метод проб и ошибок. Конечно качество ОП будет хуже, но усилий будет затрачено меньше. ARK>ИМХО, язык тут особого рояля не играет.
ЯП для программиста, это примерно как UI для пользователя ОП. ARK>Качественный набор библиотек на том же дотнете также позволит легко создавать из "кирпичей" приложения. Соответственно, интересно ваше мнение — в чем заслуга именно предлагаемого языка для создания переиспользуемого кода?
Зачем для КОП отдельный ЯП? Это прежде всего удобство и проста работы. Я считаю что лучше, например иметь язык для (с хорошей поддержкой) ФП, язык для ООП etc., чем всё в одной куче. Касательно КОП на JVM, предполагается интеграция с другими JVM-языками на уровне классов, т.е. объект может быть представлен как компонент с одним интерфейсом, а компонент как композитный объект (наверно).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[8]: Заметка: Компонентная философия и реализация
DM>В начале 90-х точно так же думали про ООП. Даже книжка была художественная на эту тему, Microserves, ужасно занудная. Там тоже были сплошь мечты "вот сейчас компонентов наделаем, останется только из них как из кубиков собирать". Но мечты не сбылись. MS удалось на этой идеологии понаделась офис и еще ряд вещей, но освободить программистов от программирования так и не вышло. Впрочем, на некотором уровне успех есть — тот же .NET столь удобен при разработке тем, что в базовой библиотеке классов уже очень много всего есть, бери да соединяй.
Почему это "на некотором уровне"? Конечно, в полном объёме мечты не сбылись, но сегодня, кроме .NET есть ещё swing, Qt и куча других библиотек классов, сильно облегчающих жизнь разработчиков чуть менее чем всего ОП. Думаю это огромный успех, по сравнению со временами Паскаля и чистого Си. Но, пришло время сделать следующий шаг! DM>Но необходимость описывать самому логику и создавать свои компоненты никуда не делась.
Она и не денется никуда. Например, в электронике сегодня существуют огромное количество разновидностей микросхем, на "каждый чих", но из-за этого не перестали использовать "рассыпуху" и создавать новые микросхемы. При разработке этого (компонентного) подхода, я учитывал то что будет необходимо создавать новые компоненты, изменять и удалять существующие. И, само по себе КОП, позволяет делать это гораздо проще и эффективней. AC>>Просто этот подход позволит сделать "пропасть", между программистами и пользователями, меньше, например, пользователь сможет собрать какую ни будь фичу сам или нанять стороннего разработчика для реализации, а не дожидаться когда её добавить разработчик программы. DM>Это уже сделано в виде Visual Basic'a, особенно VBA, который в офисе, и VBScript для скриптов в системе. Они берут готовые компоненты и дают пользователю их задействовать в как бы очень простом языке. Но на деле используются не так часто, как планировалось, почему-то. Счастье так и не наступило.
Думаю это из-за того что VB(и его близкие родственники) это ЯОН(там есть переменны, циклы и прочее), т.е. он слишком сложен для не программистов, и в тоже время слишком уныл для программистов. Если бы, например, в MS постарались и сделали для свого Word'а хороший DSL и/или визуальный редактор для управления компонентами, всё могло бы быть иначе. DM>Я не к тому, что ваш подход плох. Я к тому, что во многом он уже был реализован, и жизнь показала, что он не сделал ее сильно уж проще.
Думаю, это из-за того что реализации не были достаточно хороши. Потому что, например, насколько мне известно, в области автоматизации производства, подобный подход практически вытиснил "необходимость описывать самому логику и создавать свои компоненты".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Это не просто COM. Это философия сродни реактивному/агентному программированию, только с помощью КОП. То бишь, это парадигма над парадигмой компонент. )))
Наконец то кто-то смог выявить в этом тексте рациональное зерно.
Если принять твою мысль за истинную, то возникает два вопроса:
1. Зачем весь этот ворох слов? Ведь тебе на выражение этой мысли хватило одного абзаца.
У меня просто перехватило усидчивости чтобы вылепить эту мысль.
2. Зачем для этого создавать новые языки и рантаймы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Это не просто COM. Это философия сродни реактивному/агентному программированию, только с помощью КОП. То бишь, это парадигма над парадигмой компонент. ))) V>На самом деле единственно разумное зерно — это специальные связи компонент. Я когда-то назвал такое "пинами" в аналогичных рассуждениях: http://www.rsdn.ru/forum/philosophy/1676773.1
Здравствуйте, AlexCab, Вы писали:
VD>>1. Компонент. AC>Это почти то же что объект, он также имеет состояние и поведение. Основные отличия в интерфейсе: 1) интерфейсов может быть несколько
В СОМ, дотнете, жабе интерфейсов тоже может быть несколько.
AC>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом.
В СОМ вызов QueryInterface, в жабе и дотнете операция приведения типа.
AC>И небольшими отличиями в поведении: после выполнения конструктора, внутри компонента, в отдельном потоке, может быть запущена функция(или несколько), что делает компоненты активными(способными делать что то самостоятельно, не дожидаясь вызовов методов).
Без проблем реализуется поверх СОМ, дотнета и джавы.
AC>Отличий действительно не много
А точнее их просто нет.
AC>Возвращаясь к вопросу отличий от COM, здесь есть картинка иллюстрирующая COM-объект, а вот как выглядят ООП и КОП объекты: AC>
Автор видимо не в курсе того, что сам СОМ вообще почти ничего не говорит про внутреннюю реализацию (ну, с некоторой натяжкой, можно активацию СОМ-серверов к этому разве отнести). СОМ говорит только об интерфейсах и работе с ними, а за границей интерфейса может быть что угодно, в том числе и абсолютно необъектные функции. Так что картинка в корне неверная
VD>>Чего? Ты уверен, что понимаешь, что такое Win RT? Win RT — это новая версия COM-а от Майкрософта. Я не говорю, о Win RT в смысле API для Виндовс. Я говорю о Win RT как о компонентной технологии. AC>Windows Runtime — API Metro-приложений, основанный на технологии COM, с заточкой под .NET. Я неправильно понял?
http://en.wikipedia.org/wiki/WinRT#Services — пункты 2.1 и 2.2.
VD>>В Яве тоже есть компоненты. Что значит "нет объектов" по прежнему не понимаю. Может вопрос в определениях? Можно твое определение объекта услышать? AC>JavaBeans? Это просто набор правил кодирования.
Нет, это стандарт, позволяющий стороннему коду анализировать метаданные бинов. В джаве это в виде соглашений просто потому что обычный джавовский класс уже отвечает практически всем признакам компонента.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AC>>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом.
AVK>В СОМ вызов QueryInterface, в жабе и дотнете операция приведения типа.
Вот здесь, возможно, он имеет в виду нечто большее чем просто проверка интерфейса.
Возможно, что тут подразумевается наличие чего-то вроде реактивности. Если правильно понял подключение ему нужно для перехвата вызовов и автоматического оповещения связанных компонентов.
Причем тут только компоненты непонятно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, VladD2, Вы писали:
AVK>>В СОМ вызов QueryInterface, в жабе и дотнете операция приведения типа.
VD>Вот здесь, возможно, он имеет в виду нечто большее чем просто проверка интерфейса.
В СОМ за QueryInterface может скрываться что угодно, далеко не только проверка. Я и на практике встречал ситуации, когда QueryInterface возвращал указатель, отличный от this. Да и в дотнете такое, при желании, реализовать можно.
VD>Возможно, что тут подразумевается наличие чего-то вроде реактивности. Если правильно понял подключение ему нужно для перехвата вызовов и автоматического оповещения связанных компонентов.
Я этого, если честно, не увидел.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AlexCab, Вы писали:
AC>COM был (и есть) слишком сложен и "массивен". .NET сделали проще
Компонентная модель дотнета (и WinRT) существенно сложнее СОМ. Я уж не говорю о компонентной модели XAML, которая используется в WPF. СОМ на самом деле очень прост, но вот его использование в С++ весьма некомфортно, потому что язык под это неприспособлен. В рамках же дотнета СОМ весьма близок к родной компонентной модели.
AC>Что если сделать ещё более простую технологию?
Еще более простая технология будет нужна еще меньше СОМ.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали: VD>>>1. Компонент. AC>>Это почти то же что объект, он также имеет состояние и поведение. Основные отличия в интерфейсе: 1) интерфейсов может быть несколько AVK>В СОМ, дотнете, жабе интерфейсов тоже может быть несколько.
Наследование интерфейсов в Java это не тоже самое, что несколько отдельных интерфейсов(как в COM). AC>>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом. AVK>В СОМ вызов QueryInterface,
Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: 1) как-то организовать получение GUID интерфейса конкретного компонента, 2) оба взаимодействующих компонента должны получить таблицы методов(QueryInterface), 3) оба компонента должны проверить наличие функций "connection", и если таковые есть, вызвать. И это только установка связи, и ещё кучу всего нужно будет реализовать для разрыва(обычного и аварийного) связи.
В КОП это делается парой операторов("connect", "disconnect"), остальное забота рантайма. AVK>в жабе и дотнете операция приведения типа.
Причём здесь приведение типа? Оно лишь, даёт возможность скрыть/показать часть полей объекта. Управление интерфейсами в КОП похоже на управление Qt'ишными слотами-сигналами. AC>>И небольшими отличиями в поведении: после выполнения конструктора, внутри компонента, в отдельном потоке, может быть запущена функция(или несколько), что делает компоненты активными(способными делать что то самостоятельно, не дожидаясь вызовов методов). AVK>Без проблем реализуется поверх СОМ, дотнета и джавы.
В КОП поддерживается "из коробки". AC>>Отличий действительно не много AVK>А точнее их просто нет.
Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса и поддержки рантайма, для этого будет нужна куча соглашений, которая превратится в кучу служебного кода, что есть дополнительный, не нужный геморрой для программистов. К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит. AVK>Автор видимо не в курсе того, что сам СОМ вообще почти ничего не говорит про внутреннюю реализацию (ну, с некоторой натяжкой, можно активацию СОМ-серверов к этому разве отнести). СОМ говорит только об интерфейсах и работе с ними, а за границей интерфейса может быть что угодно, в том числе и абсолютно необъектные функции.
Наверно автор писал о том как это делают обычно, а не о том какими, "нетрадиционными", способами это можно сделать в принципе. AVK>Так что картинка в корне неверная
Мопед не мой. AC>>Windows Runtime — API Metro-приложений, основанный на технологии COM, с заточкой под .NET. Я неправильно понял? AVK>http://en.wikipedia.org/wiki/WinRT#Services — пункты 2.1
Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом.
В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают. К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода. AVK>и 2.2.
.NET'овская система типов в COM? Аналогичное предыдущему. AC>>JavaBeans? Это просто набор правил кодирования. AVK>Нет, это стандарт, позволяющий стороннему коду анализировать метаданные бинов. JavaBeans, не нашёл про анализ метаданных AVK>В джаве это в виде соглашений просто потому что обычный джавовский класс уже отвечает практически всем признакам компонента.
А где это ещё используется кроме Java?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
AC>>>; 2) интерфейсы управляемы, т.е., в отличии от ООП где любой объект может в любое время вызвать метод любого другого объекта, в КОП, компонент предварительно должен "установить связь" с другим компонентом. AVK>>В СОМ вызов QueryInterface, в жабе и дотнете операция приведения типа. VD>Вот здесь, возможно, он имеет в виду нечто большее чем просто проверка интерфейса. VD>Возможно, что тут подразумевается наличие чего-то вроде реактивности.
Нет, это не совсем про реактивность. VD>Если правильно понял подключение ему нужно для перехвата вызовов
Грубо говоря, для получения таблицы методов, как в COM'е, и... VD>и автоматического оповещения связанных компонентов.
... да, для "оповещения" связывающихся компонентов.
VD>Причем тут только компоненты непонятно. Component-based software engineering
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Заметка: Компонентная философия и реализация
AC>>COM был (и есть) слишком сложен и "массивен". .NET сделали проще AVK>Компонентная модель дотнета (и WinRT) существенно сложнее СОМ. Я уж не говорю о компонентной модели XAML, которая используется в WPF. СОМ на самом деле очень прост, но вот его использование в С++ весьма некомфортно, потому что язык под это неприспособлен. В рамках же дотнета СОМ весьма близок к родной компонентной модели.
Простота использования имелась ввиду, же.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[4]: Заметка: Компонентная философия и реализация
VD>1. Зачем весь этот ворох слов? Ведь тебе на выражение этой мысли хватило одного абзаца. VD>У меня просто перехватило усидчивости чтобы вылепить эту мысль.
Хотел чтобы у вас сложилось как можно более полное представление о КОП(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике. VD>2. Зачем для этого создавать новые языки и рантаймы? Для удобства использования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Наследование интерфейсов в Java это не тоже самое, что несколько отдельных интерфейсов(как в COM).
Наследование — конечно нет, в СОМ наследование вообще отсуствует. А вот реализация интерфейсов вполне себе то же самое.
AVK>>В СОМ вызов QueryInterface, AC>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: 1) как-то организовать получение GUID интерфейса конкретного компонента
И?
AC>2) оба взаимодействующих компонента должны получить таблицы методов(QueryInterface)
И?
AC>, 3) оба компонента должны проверить наличие функций "connection", и если таковые есть, вызвать.
И?
AC>В КОП это делается парой операторов("connect", "disconnect"), остальное забота рантайма.
Каких операторов? Смешались в кучу кони, люди. СОМ это компонентная модель, операторы это языковые сущности. Ничто не мешает создать язык с парой операторов, работающий с СОМ. Или даже язык, который в QueryInterface со всеми танцами превращает обычную операцию приведения типов.
AVK>>в жабе и дотнете операция приведения типа. AC>Причём здесь приведение типа?
Притом, что это семантический эквивалент QueryInterface.
AC> Оно лишь, даёт возможность скрыть/показать часть полей объекта.
Приведение к интерфейсу к полям вообще никакого отношения не имеет — интерфейс поля не содержит, только методы. И операция приведения семантически означает запрос определенного контракта с контролем его наличия. Т.е. ровно то же самое, что делает QueryInterface и твои мифические connect/disconnect. Причем этот вариант существенно более гибок, так как не требует реактивности в обязательном порядке (но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера).
AVK>>Без проблем реализуется поверх СОМ, дотнета и джавы. AC>В КОП поддерживается "из коробки".
КОП это парадигма. Никакой коробки нет. Ну и в дотнете это тоже практически искаропки — про reactive extensions я уже писал. Для жабы наверняка тоже что то есть.
AC>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса
Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка.
AC>К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит.
Проснись, все что ты хочешь уже есть.
AC>Наверно автор писал о том как это делают обычно
Мне больше кажется, что автор просто не разобрался в том, что же такое СОМ. Потыркался в васике с компонентами и решил, что он уже все знает.
AVK>>http://en.wikipedia.org/wiki/WinRT#Services — пункты 2.1 AC>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом.
И что?
AC>В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают.
Это какая то реализационная муть, которая к дизайну компонентной модели вообще никакого отношения не имеет.
AC> К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода.
А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)?
AVK>>Нет, это стандарт, позволяющий стороннему коду анализировать метаданные бинов. AC>JavaBeans, не нашёл про анализ метаданных
А меня тоже ссылки надежные есть. Так что давай лучше оперировать фактами, а не давать ссылки черт знает куда.
А факты ведь упрямая. Реактивное программирование прекрасно работает и без компонентов (хотя может и с ними). Соответственно приплетать его к компонентному подходу смысла не имеет.
Так же расстрою тебя еще одним фактом. Создавать ПО на базе одних лишь компонентов физически невозможно. Компоненты имеют смысл только там где требуются относительно большие блоки.
Скажу больше, компонентные технологии область довольно хорошо разработанная и революциями в ней не пахнет.
Лично я увлекался этим делом где-то в середине 90-х. Этот подход сулил серьезные бенефиты в области корпоративных систем (которые тогда были востребованы). Но чем больше я узнавал в этой области, тем больше понимал, что это не более чем полезный прием программирования. И самого программирования (т.е. написания большого количества кода) он не отменяет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Хотел чтобы у вас сложилось как можно более полное представление о КОП
Давай начнем с того, что КОП я занимался без малого 10 лет. Стало быть, если ты и правда придумал что-то новое, то не стоит называть это КОП, так как термин уже использован.
AC>(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике.
В теории вообще все давно известно. На любом полном по Тьюрингу языке можно написать любую программу, если конечно хватит сил и программа не рассыпется от багов, или не станет полностью непонятной. По сему людей интересуют лишь способы упростить программирование теряя при этом минимум производительности конечного приложения.
VD>>2. Зачем для этого создавать новые языки и рантаймы? AC>Для удобства использования.
AVK>Наследование — конечно нет, в СОМ наследование вообще отсуствует. А вот реализация интерфейсов вполне себе то же самое.
Так мы же про интерфейсы, а не про их реализацию. AVK>>>В СОМ вызов QueryInterface, AC>>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: AVK>И? AVK>И? AVK>И?
И это сложнее чем использовать готовое, например. AVK>Каких операторов? Смешались в кучу кони, люди. СОМ это компонентная модель, операторы это языковые сущности. Ничто не мешает создать язык с парой операторов, работающий с СОМ. Или даже язык, который в QueryInterface со всеми танцами превращает обычную операцию приведения типов.
COM мало распространён, не целесообразно делать язык только для него. Я хочу чтобы это работало на(поверх) JVM(это ООП), и возможно в будущем на x86. То есть решение должно быть более обобщённым чем просто настройка над COM. AVK>>>в жабе и дотнете операция приведения типа. AC>>Причём здесь приведение типа? AVK>Притом, что это семантический эквивалент QueryInterface. QueryInterface, Java — 8. Преобразование типов. AC>> Оно лишь, даёт возможность скрыть/показать часть полей объекта. AVK>Приведение к интерфейсу к полям вообще никакого отношения не имеет — интерфейс поля не содержит, только методы.
Виноват исправлюсь, конечно же методы. AVK>И операция приведения семантически означает запрос определенного контракта с контролем его наличия.
Всё таки наверно эта операция семантически означает именно приведение типа, в процессе которого может выполнятся(а может и не выполнятся, если это происходит компилтайм) запрос и контроль. AVK>Т.е. ровно то же самое, что делает QueryInterface
QueryInterface делает именно запрос, он не выполняет приведение. AVK>и твои мифические connect/disconnect.
А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса. В процессе которых может выполнятся запрос и не может приведение(типы интерфейсов не наследуются). AVK>Причем этот вариант существенно более гибок, так как не требует реактивности в обязательном порядке
В КОП реактивность также не требуется(тем более в обязательном порядке), но поддерживаться на уровне ЯП. AVK>(но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера). Это похоже на урезанный Erlang, простым в использовании я бы это не назвал. AC>>В КОП поддерживается "из коробки". AVK>КОП это парадигма. Никакой коробки нет.
В обсуждаемой реализации, уточняю. AC>>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса AVK>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка.
Я этого не утверждал. AC>>К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит. AVK>Проснись, все что ты хочешь уже есть.
Есть только кусочками в разных местах, я хочу собрать всё это воедино. AC>>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом. AVK>И что?
И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше. AC>>В КОП тоже есть метаданные, но в отличии от, нет необходимости тащить в пакет(в терминах Java) описание каждого метода и класса, достаточно набора сигнатур типов интерфейсов. Если тип(сигнатура) интерфейса сервера и клиента(в терминах COM, в КОП явного разделения нет) совпадает, значит типы методов(аргументов-результатов) и свойств так же совпадают. AVK>Это какая то реализационная муть, которая к дизайну компонентной модели вообще никакого отношения не имеет.
Это было маленькое отступление о метаданных, в обсуждаемой реализации КОП. AC>> К тому же проверка сигнатуры выполняется только при подключении интерфейса, а не для каждого вызова метода. AVK>А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)? Так утверждает википедия:
Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе. Это гарантирует, что метод может быть вызван именно с корректным числом параметров и именно с корректными типами параметров.
Как оно реально работает, я не знаю.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[6]: Заметка: Компонентная философия и реализация
VD>Давай начнем с того, что КОП я занимался без малого 10 лет. Стало быть, если ты и правда придумал что-то новое, то не стоит называть это КОП, так как термин уже использован.
Это не что-то новое, это до/пере пиленое классическое КОП(с компонентами, интерфейсами и всяким таким).
Предложи другое название AC>>(там ведь есть не только пины), в частности о том какие перспективы открывает этот подход в теории, и о том как это может быть реализовано на практике. VD>В теории вообще все давно известно. На любом полном по Тьюрингу языке можно написать любую программу, если конечно хватит сил и программа не рассыпется от багов, или не станет полностью непонятной. По сему людей интересуют лишь способы упростить программирование теряя при этом минимум производительности конечного приложения.
Честно, три раза прочитал, не понял. Теории не нужны, что ли?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[9]: Заметка: Компонентная философия и реализация
AC>>Грубо говоря, для получения таблицы методов, как в COM'е, и... VD>Так и в чем тогда разница?
1)Грубо говоря(так как это может быть реализовано и без всяких таблиц методов), подключающийся компонент передаёт другому таблицу экспортируемых методов и получает от другого таблицу импортируемых(экспортируемых другим) методов, т.е. компоненты обмениваются таблицами(а не один передаёт другому как в COM). VD>>>и автоматического оповещения связанных компонентов. AC>>... да, для "оповещения" связывающихся компонентов. VD>Вот и раскрой этот момент по подробнее.
2)Компоненты, устанавливающие/разрывающие связь, получают извещение в виде вызова специальных методов, что позволяет им реагировать на эти события. VD>>>Причем тут только компоненты непонятно. AC>>Component-based software engineering VD>А меня тоже ссылки надежные есть.Так что давай лучше оперировать фактами, а не давать ссылки черт знает куда. VD>А факты ведь упрямая. Реактивное программирование прекрасно работает и без компонентов (хотя может и с ними). Соответственно приплетать его к компонентному подходу смысла не имеет.
Компоненты с реактивным программированием лучше чем компоненты без. VD>Так же расстрою тебя еще одним фактом. Создавать ПО на базе одних лишь компонентов физически невозможно.
Наверно так думали о про ООП во времена C++, но потом появилась Java, Ruby etc. VD>Компоненты имеют смысл только там где требуются относительно большие блоки.
Почему маленькие блоки не имеют смысла? VD>Скажу больше, компонентные технологии область довольно хорошо разработанная и революциями в ней не пахнет.
Откуда такая уверенность? VD>Лично я увлекался этим делом где-то в середине 90-х. Этот подход сулил серьезные бенефиты в области корпоративных систем (которые тогда были востребованы). Но чем больше я узнавал в этой области, тем больше понимал, что это не более чем полезный прием программирования. И самого программирования (т.е. написания большого количества кода) он не отменяет.
Сейчас, в своём текущем виде, да. Но и то, по сравнению с 90-ми КОП существенно развилось(например в том же .NET), и теперь помогает писать меньше "большого количества кода".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Какие ж они глобальные? Это конечно не чистое ФП, когда "состояние программы это состояние всех функций", но чтобы один компонент смог изменить другой он должен: 1) иметь соответствующий интерфейс; 2) в принципе "знать"(знать имя или как-то получить хендл) о другом. К тому же другой компонент может и не разрешить себя изменять.
ФП — это когда все состояние передается в качестве аргументов функций. Если есть глобальное состояние, то это уже не ФП.
То что описываешь ты — это императивное программирование и ООП, в частности.
Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления.
Интерфейсы вообще никак не связаны с состоянием. Можно легко создать интерфейс не меняющий состояния объектов.
А вот изменение компонента компонентом — это изменение состояния объектов, что уже 100% не ФП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AVK>>>>В СОМ вызов QueryInterface, AC>>>Чтобы в COM организовать работу с интерфейсами как в КОП, нужно: AVK>>И? AVK>>И? AVK>>И? AC>И это сложнее чем использовать готовое, например.
Ты по прежнему не можешь уловить разницу между компонентной моделью и конкретным средством создания компонентов.
AC>COM мало распространён
Решил КО побыть? Что ты хотел сказать?
AVK>>Т.е. ровно то же самое, что делает QueryInterface AC>QueryInterface делает именно запрос, он не выполняет приведение.
В чем разница?
AC>А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса.
В чем разница?
AVK>>(но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера). AC>Это похоже на урезанный Erlang, простым в использовании я бы это не назвал.
Статья, мягко говоря, так себе. Начни лучше с этого — http://channel9.msdn.com/Events/MIX/MIX10/FTL01
AC>>>Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса AVK>>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка. AC>Я этого не утверждал.
Это напрямую следует из твоего утверждения, что предложенное тобой не может быть реализовано поверх СОМ с удобным синтаксисом.
AC>>>Добавили в COM метаданные из .NET'а, это плюс к совместимости и безопасности. Но COM остался COM'ом. AVK>>И что? AC>И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше.
Практический вывод из этого какой?
AVK>>А ты думаешь в WinRT она выполняется при каждом вызове? Или что у методов нет токенов (это твои сигнатуры так на самом деле называются)? AC>Так утверждает википедия: AC>[q]Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе.
В момент JIT компиляции она это делает, а не при непосредственном выполнении. Причем уже в IL фигурирует токен метода, а не его метаданные. Метаданные хранятся отдельно. И не читайте русскую википедию, она гадость.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>>..."состояние программы это состояние всех функций"... VD>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления.
От сюда:
Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>>>..."состояние программы это состояние всех функций"... VD>>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления. AC>От сюда: AC>
AC>Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Да там горе-переводчик криво перевел. В оригинале, на который ссылка там же: "The global state of the system is carried into all functions and comes out from all functions.".
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
VD>>Запомни на будущее. ФП это кода изменение данных происходит исключительно по средствам возврата новых значений из функции. Состояния у фукнций не бывает. Бывает стек вызовов или разные там контюниэшоны, но это не состояние всех функций, а состояние процесса вычисления. AC>От сюда: AC>
AC>Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Очень много в наши дни непроверенной пурги. На хабре его выше крыши. Так что читай этот ресурс с осторожностью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Заметка: Компонентная философия и реализация
AVK>Ты по прежнему не можешь уловить разницу между компонентной моделью и конкретным средством создания компонентов.
Скромно напоминаю: мы обсуждаем компонентную модель(и средства создания компонентов) хоть и похожую на COModel, но всё таки отличающеюся от неё. И чтобы устранить эти отличия, т.е. привести обсуждаемую модель к COM, т.е. чтобы обсуждаемая модель работала поверх COM, нужно сделать "И?И?И?" и ещё много чего. AC>>COM мало распространён AVK>Спасибо, насмешил.
Всяко меньше чем JVM. AVK>>>Притом, что это семантический эквивалент QueryInterface. AC>>QueryInterface, Java — 8. Преобразование типов. AVK>Решил КО побыть? Что ты хотел сказать?
Что это разные вещи и семантически, и синтаксически. AC>>QueryInterface делает именно запрос, он не выполняет приведение. AVK>В чем разница?
Как разница между словами "получить" и "преобразовать". Как бы, похоже, но не то. AC>>А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса. AVK>В чем разница?
Например, в процессе: преобразование интерфейса сложнее(состоит из большего числа логических действий) чем получение интерфейса, а подключение интерфейса сложнее чем преобразование.
Или например, в исходном и конечном состоянии: в первом случае изначально есть один интерфейс, в конце другой; во втором изначально нет ни одного интерфейса(есть только GUID интерфейса), в конце есть интерфейс(в виде таблицы методов); в третьем(для connect) изначально есть имя интерфейса, имя/хендл компонента и первая(экспортируемая) часть реализации интерфейса, в конце есть вторая(импортирования) часть реализации интерфейса, плюс выполнена функция-событие подключения. AC>>Это похоже на урезанный Erlang, простым в использовании я бы это не назвал. AVK>Статья, мягко говоря, так себе. Начни лучше с этого — http://channel9.msdn.com/Events/MIX/MIX10/FTL01
Спасибо, вечером посмотрю. AVK>>>Попробуй доказать свой тезис, что СОМ как то влияет на синтаксис языка. AC>>Я этого не утверждал. AVK>Это напрямую следует из твоего утверждения, что предложенное тобой не может быть реализовано поверх СОМ с удобным синтаксисом.
Ох-хох, этого я точно не утверждал. "Я не спорю, всё предложенное в заметке может быть реализовано поверх ООП или COM'а. Но, без удобного синтаксиса и поддержки рантайма, для этого будет нужна куча соглашений..." — написал я. Как из этого следует, что удобный синтаксис и рантайм не могут быть реализованы по верх COM'а? AC>>И это значит что мы обсуждаем практически тот же, старый добрый COM, а не новую технологию программирования от MS, как предполагалось выше. AVK>Практический вывод из этого какой?
эта версия КОП != COM & WinRT AC>>[q]Когда среда CLR исполняет CIL она делает проверку того, что метаданные вызываемого метода совпадают с метаданными, хранящимися в вызывающем методе. AVK>В момент JIT компиляции она это делает, а не при непосредственном выполнении. Причем уже в IL фигурирует токен метода, а не его метаданные. Метаданные хранятся отдельно. И не читайте русскую википедию, она гадость.
Токен проверяется при каждом вызове?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[4]: Заметка: Компонентная философия и реализация
DM>И это тоже уже реализовано в DirectShow, например. Как раз на базе СОМ. Там пины так и называются пинами. Имеют четкие интерфейсы и т.д. Есть графические среды для создания графов из таких компонентов, в том числе с генерацией кода.
А где реклама одного из них?
=============
Ясен пень, что идея соединения через "пины" с последующим построением приложений из "кубиков" на поверхности. Но DirectShow слишком уж ограниченный для общих нужд, как и любая другая подобная система, где типы пинов заданы "сверху".
Re[4]: Заметка: Компонентная философия и реализация
Здравствуйте, VladD2, Вы писали:
VD>Наконец то кто-то смог выявить в этом тексте рациональное зерно. VD>Если принять твою мысль за истинную, то возникает два вопроса: VD>1. Зачем весь этот ворох слов? Ведь тебе на выражение этой мысли хватило одного абзаца.
Согласен, автору стоило самому сначала разобраться, где именно на его "модели" полезно было бы сфокусироваться и почему. Ведь всё аналогичное уже есть, надо было лишь показать предполагаемые бонусы.
VD>У меня просто перехватило усидчивости чтобы вылепить эту мысль. VD>2. Зачем для этого создавать новые языки и рантаймы?
Для поддержки необходимых ограничений, ес-но.
В дотнете пин можно упрощенно представить как объект со всего одним событием с одной стороны (выходной пин), и функциональный объект с другой (входной пин). Вот почему я упомянул реактивное программирование — это оно есть. Разница лишь в том, что это реактивное программирование приспособлено для КОП. Т.е. вместо объектов с кучей выходных пропертей (и событий об изменении к ним) с одной стороны и кучей методов (или входных пропертей) с другой, мы переходим к компонентам с кучей пинов с обоих сторон. Что это даёт? Да ничего нового, если смотреть чисто с филосовской точки зрения — биндинг в дотнете предоставляет аналогичные возможности... но очень много, есть вспомнить, что речь о статически-компиллируемых языках. В описанном мною виде каждый пин сам себе является Property/Event/MemberDescriptor, то бишь биндинг может происходить в рантайм или compile-time в типизированной манере, с соблюдением жестких контрактов, в отличие от предлагаемо нетипизированной возни через рефлексию + ComponentModel в дотнете (с пролетающими мимо системы типов, но тем не менее неразрывными связями некоего property Xxx и 2-х events к нему: onXxxChanging/onXxxChanged).
В итоге становится легко строить программы "топологически", просто соединяя пины подходящих типов, без вероятности допустить ошибку в (сугубо умозритрительном на сегодня) контракте для биндинга. Ну и лаконичность, опять же. Сейчас обслуживание одного пина настолько размазано по коду, насколько вообще возможно нарушить SRP, увы.
============
См. всевозможные костыли-вариации на тему биндинга в дотнете. Фиг с ней уже, с ComponentModel... первый блин комом.. Ну ей-богу, без слёз смотреть на этот XML-роутинг событий в WPF невозможно. Если бы электронщики так же плутали в 3-х соснах при роутинге сигналов, мы бы до сих пор не продвинулись дальше 4-хразрядных калькуляторов. См. современные языки для реактивного программирования (то бишь для разработки аппаратуры), типа VHDL: D1: NAND2 port map (a => a, b => b, c => s1); Эквивалентный код в C# или WPF-XML просто нечитабелен. То бишь имеющиеся языки де-факто не приспособлены для компонентного программирования.
И да, мы знаем, что уж на Немерле можно много чего, было бы желание. )
Вот вам еще одна одна тема для библиотек. Жаль, что существующий WPF не натянешь на предполагаемую модель, нужно разработать с 0-ля. А для ComponentModel, WPF и прочих недо-КОП legacy code сделать кодогенератор оберток для уже существующих компонент под новую модель.
Re[4]: Заметка: Компонентная философия и реализация
V>>Это не просто COM. Это философия сродни реактивному/агентному программированию, только с помощью КОП. То бишь, это парадигма над парадигмой компонент. ))) V>>На самом деле единственно разумное зерно — это специальные связи компонент. Я когда-то назвал такое "пинами" в аналогичных рассуждениях: http://www.rsdn.ru/forum/philosophy/1676773.1
ARK>Спасибо, очень интересная точка зрения. Мне нравится, концептуально очень изящно. Может быть есть какие-то реализации или языки с подобной философией?
Из имеющихся подобных языков — только для разработки аппаратуры. ))
Можно взять Немерле и на нем попробовать сделать подобную библиотеку для софта.
Re[11]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Скромно напоминаю: мы обсуждаем компонентную модель(и средства создания компонентов) хоть и похожую на COModel, но всё таки отличающеюся от неё.
Ну так вот отличия именно модели ты так и не смог продемонстрировать, все время скатываешься с модели на детали реализации типа ключевых слов в языке или токенов методов.
AC>>>QueryInterface делает именно запрос, он не выполняет приведение. AVK>>В чем разница? AC>Как разница между словами "получить" и "преобразовать". Как бы, похоже, но не то.
Это все софистика, а не ответ на вопрос.
AC>>>А мои мифические connect/disconnect _не_ делают ни запроса, ни приведения. Они делают соединение/разъединение интерфейса. AVK>>В чем разница? AC>Например, в процессе: преобразование интерфейса сложнее(состоит из большего числа логических действий) чем получение интерфейса, а подключение интерфейса сложнее чем преобразование.
Это не ответ на вопрос, а игра словами.
AC>Или например, в исходном и конечном состоянии: в первом случае изначально есть один интерфейс, в конце другой; во втором изначально нет ни одного интерфейса(есть только GUID интерфейса), в конце есть интерфейс(в виде таблицы методов); в третьем(для connect) изначально есть имя интерфейса, имя/хендл компонента и первая(экспортируемая) часть реализации интерфейса, в конце есть вторая(импортирования) часть реализации интерфейса, плюс выполнена функция-событие подключения.
Это — детали реализации. К модели это не относится.
AVK>>В момент JIT компиляции она это делает, а не при непосредственном выполнении. Причем уже в IL фигурирует токен метода, а не его метаданные. Метаданные хранятся отдельно. И не читайте русскую википедию, она гадость. AC>Токен проверяется при каждом вызове?
Я непонятно написал? "В момент JIT компиляции она это делает". При выполнении там обычный статический или виртуальный вызов, как в обычном нативном языке типа С++.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>>Скромно напоминаю: мы обсуждаем компонентную модель(и средства создания компонентов) хоть и похожую на COModel, но всё таки отличающеюся от неё. AVK>Ну так вот отличия именно модели ты так и не смог продемонстрировать, все время скатываешься с модели на детали реализации типа ключевых слов в языке или токенов методов. AC>>Или например, в исходном и конечном состоянии: в первом случае изначально есть один интерфейс, в конце другой; во втором изначально нет ни одного интерфейса(есть только GUID интерфейса), в конце есть интерфейс(в виде таблицы методов); в третьем(для connect) изначально есть имя интерфейса, имя/хендл компонента и первая(экспортируемая) часть реализации интерфейса, в конце есть вторая(импортирования) часть реализации интерфейса, плюс выполнена функция-событие подключения. AVK>Это — детали реализации. К модели это не относится.
Где заканчивается модель, и начинаются детали реализации?
Или опиши модель, а я опишу отличия.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[13]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Где заканчивается модель, и начинаются детали реализации?
А ты сам не в состоянии границу провести? Модель это обязательные контракты компонентной инфраструктуры, идентичные в разных реализациях. То, что от реализации к реализации меняется моделью не является.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>>Где заканчивается модель, и начинаются детали реализации? AVK>А ты сам не в состоянии границу провести? Модель это обязательные контракты компонентной инфраструктуры, идентичные в разных реализациях. То, что от реализации к реализации меняется моделью не является.
Ok, для обсуждаемой модели компонентно-ориентированного программирования, навскидку обязательны(т.е. без этого модель(а точнее любую её реализацию) невозможно будет использовать в полной мере, для разработки ПО, описанными в заметке способами):
1)Компоненты имеющие состояние и поведение.
2)Сборки.
3)Интерфейсы, в таком виде как они описаны выше.
4)Потоки внутри компонентов(упоминашиеся выше).
Остальное, описанное в заметке, будучи реализованным как-то иначе, думаю, существенно не повлияет на основные возможности модели(сборка из компонентов, агентное/реактивное программирование etc.).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[15]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>1)Компоненты имеющие состояние и поведение. AC>2)Сборки. AC>3)Интерфейсы, в таком виде как они описаны выше. AC>4)Потоки внутри компонентов(упоминашиеся выше).
Ну то есть берем дотнет, добавляем к нему простенький фреймворк (в идеале спецязык) и средства реактивного программирования и получаем то что ты хочешь. И это все? В чем новизна идеи?
AC>Остальное, описанное в заметке, будучи реализованным как-то иначе, думаю, существенно не повлияет на основные возможности модели(сборка из компонентов, агентное/реактивное программирование etc.).
Потоки внутри компонентов это и есть вариация на тему реактивного программирования.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AVK>Ну то есть берем дотнет, добавляем к нему простенький фреймворк (в идеале спецязык) и средства реактивного программирования и получаем то что ты хочешь. И это все?
Ну да! Только не .NET, а JVM и, не фреймворк, а полноценный ЯП(например как Scala) с встроенными средствами для реактивного программирования. AVK> В чем новизна идеи?
В собственно подходе(описанному во второй главе заметки) к программированию в целом, и к созданию и использованию компонентов в частности. А ЯП и рантайм нужны чтобы, для программиста, реализация этого подхода на практике была максимально комфортной и эффективной. AVK>Потоки внутри компонентов это и есть вариация на тему реактивного программирования.
Нет, эти потоки (выполнения) для агентного программирования. Для реактивного — потоки значений с возможностью организации очередей между компонентами.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[10]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>1)Грубо говоря(так как это может быть реализовано и без всяких таблиц методов), подключающийся компонент передаёт другому таблицу экспортируемых методов и получает от другого таблицу импортируемых(экспортируемых другим) методов, т.е. компоненты обмениваются таблицами(а не один передаёт другому как в COM).
Сократи содержимое обоих таблиц до 1-го вхождения, и получишь базовую модель для реактивного программирования. )
То бишь, в одном интерфейсе будет всего один сигнал. Итого, у компонента будет не много сигналов на каждый интерфейс, а много интерфейсов, где в каждом всего 1 сигнал. Но! Подобные интерфейсы должны быть в виде экземпляров, а не в виде уникальных контрактов... Ууупс!!! )) Поэтому модель контрактов современного ООП на реактивное программирование ни разу не ложится — слишком высока связанность для этого.
Тут правильно сказали, что можно смотреть идеологию DirectShow. Что удобно в такой архитектуре — развязываются руки в относительно подключений компонент друг к другу. Почему? Из-за того, что кол-во сигналов обычно невелико, т.е., имея в базисе сигналы (т.е. ориентируя архитектуру на сигналы, вернее на топологию их прохождения), мы получаем очень и очень низкую связанность компонент при всё еще существующей типобезопасности.
Re[8]: Заметка: Компонентная философия и реализация
Здравствуйте, AndrewVK, Вы писали:
AVK>Притом, что это семантический эквивалент QueryInterface.
Не совсем. Это семантический эквивалент на механику вокруг IConnectionPoint/IConnectionPointContainer, а так же их IDispatch-эквивалент. Это аналог джавовских листенеров событий. Всё это "красиво" встроено в язык VB/VBA, но в С++, Джаве и дотнете аналогичное только ручками.
AC>> Оно лишь, даёт возможность скрыть/показать часть полей объекта.
AVK>Приведение к интерфейсу к полям вообще никакого отношения не имеет — интерфейс поля не содержит, только методы. И операция приведения семантически означает запрос определенного контракта с контролем его наличия. Т.е. ровно то же самое, что делает QueryInterface и твои мифические connect/disconnect. Причем этот вариант существенно более гибок, так как не требует реактивности в обязательном порядке (но при этом вполне позволяет ее реализовать при желании — можешь посмотреть на Reactive Extensions в дотнете для примера).
Дык, реактивность требует некоторой поддержки. Например, VB превращает листенеры в нечто гораздо более "реактивное" за счет упрятанной в язык всей механики. В итоге, можно оперировать контрактами обратного вызова "поэлементно", т.е. так, как будто бы каждый callback независим от других.
AC>>К тому же каждый будет реализовывать это всё по своему, в общем будет адъ и погибель, и компонентное будущее та и не наступит. AVK>Проснись, все что ты хочешь уже есть.
Оно есть в ООП, ес-но. Но нет поддержки в мейнстриме.
Re[11]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали: AC>>1)Грубо говоря(так как это может быть реализовано и без всяких таблиц методов), подключающийся компонент передаёт другому таблицу экспортируемых методов и получает от другого таблицу импортируемых(экспортируемых другим) методов, т.е. компоненты обмениваются таблицами(а не один передаёт другому как в COM). V>Сократи содержимое обоих таблиц до 1-го вхождения, и получишь базовую модель для реактивного программирования. )
Можно определить интерфейс с одним импортируемым и одним экспортируемым методом, но, думаю, запрещать определять больше методов не очень хорошая идея. V>То бишь, в одном интерфейсе будет всего один сигнал. Итого, у компонента будет не много сигналов на каждый интерфейс, а много интерфейсов, где в каждом всего 1 сигнал. Но! Подобные интерфейсы должны быть в виде экземпляров, а не в виде уникальных контрактов... Ууупс!!! ))
Много интерфейсов — плохо. Это почти тоже самое что ООП, в котором много методов. В КОП, одна из главных задач интерфейсов — упорядочивание и упрощение связей компонентов(а значит и системы в целом). Что достигается объединением логически связынных методов и полей в один интерфейс, и запретом доступа к ним, если компонент не поддерживает данный интерфейс и интерфейс не подключён, в отличии от ООП где любой объект в любое время может вызывать любой метод другого объекта.
К тому же станет невозможно писать в ООП стиле, что сделает переход к компонентному программированию сложнее для программистов. V>Поэтому модель контрактов современного ООП на реактивное программирование ни разу не ложится — слишком высока связанность для этого.
Раскрой пожалуйста мысль. V>Тут правильно сказали, что можно смотреть идеологию DirectShow. Что удобно в такой архитектуре — развязываются руки в относительно подключений компонент друг к другу. Почему? Из-за того, что кол-во сигналов обычно невелико, т.е., имея в базисе сигналы (т.е. ориентируя архитектуру на сигналы, вернее на топологию их прохождения), мы получаем очень и очень низкую связанность компонент при всё еще существующей типобезопасности.
Т.е. один пин должен мочь принимать несколько типов сигналов?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[9]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Не совсем. Это семантический эквивалент на механику вокруг IConnectionPoint/IConnectionPointContainer
По заявлениям ТС, реактивность не есть обязательный признак. Так что нет.
V>, а так же их IDispatch-эквивалент. Это аналог джавовских листенеров событий. Всё это "красиво" встроено в язык VB/VBA, но в С++, Джаве и дотнете аналогичное только ручками.
Аналогичное что? С шарпе IConnectionPoint превращается в обыкновенное событие. При желании можно завернуть в IObservable.
V>Дык, реактивность требует некоторой поддержки
Какой?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>Глобальное состояние системы хранится во всех функциях и вытекает изо всех функций.
Более точно состояние в ФП хранится в локальных переменных по всему стеку вызова. То бишь, в состояние в ФП входит состояние стека и положение указателя команд.
ООП/императив отличается тем, что состояния делят на целевые и промежуточные. Проектирую обычно только целевые состояния, а проходы по промежуточным стараются делать как можно более безопасными (в идеале — транзакционными). В этом смысле в ФП все состояния — промежуточные. ))
Re[4]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Из имеющихся подобных языков — только для разработки аппаратуры. )) V>Можно взять Немерле и на нем попробовать сделать подобную библиотеку для софта.
Понял.
Подумалось еще вот что. А как в вашей модели дело обстоит с приемом сигналов в произвольные моменты времени? По идее, компонент может применяться в многопоточном окружении (он сам не знает, где применяется, поэтому рассчитывает на худшее). Получается, внутри будет куча всяких локов и прочих синхронизаций? Или же состояния у компонента вообще не может быть в принципе, и каждый выход — просто функция от всех входов? (Наверное, так и есть. )
Re[12]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>>>1)Грубо говоря(так как это может быть реализовано и без всяких таблиц методов), подключающийся компонент передаёт другому таблицу экспортируемых методов и получает от другого таблицу импортируемых(экспортируемых другим) методов, т.е. компоненты обмениваются таблицами(а не один передаёт другому как в COM). V>>Сократи содержимое обоих таблиц до 1-го вхождения, и получишь базовую модель для реактивного программирования. ) AC>Можно определить интерфейс с одним импортируемым и одним экспортируемым методом, но, думаю, запрещать определять больше методов не очень хорошая идея.
Нужен всего один метод. Идея нормальная — ведь в отсутствии таблицы получишь уменьшение косвенности на 1 (если сам делаешь рантайм).
Одна сторона (выходная) этот метод вызывает, другая сторона — подставляет функтор (пин) для вызова.
V>>То бишь, в одном интерфейсе будет всего один сигнал. Итого, у компонента будет не много сигналов на каждый интерфейс, а много интерфейсов, где в каждом всего 1 сигнал. Но! Подобные интерфейсы должны быть в виде экземпляров, а не в виде уникальных контрактов... Ууупс!!! )) AC>Много интерфейсов — плохо. Это почти тоже самое что ООП, в котором много методов.
Это если смотреть на интерфейсы как на типы. А ты смотри на них как на экземпляры. И тогда пусть их будет хоть сотни — это не мешает ни чему.
AC>В КОП, одна из главных задач интерфейсов — упорядочивание и упрощение связей компонентов(а значит и системы в целом). Что достигается объединением логически связынных методов и полей в один интерфейс, и запретом доступа к ним, если компонент не поддерживает данный интерфейс и интерфейс не подключён, в отличии от ООП где любой объект в любое время может вызывать любой метод другого объекта.
Мммм... сорри, но вынужден отослать к OLE/ActiveX. В реальности, никакого упрощения НЕТ.
1. Обычно интерфейсы не самодостаточны, а взаимодействуют со многими другими интерфейсами, если посмотреть на протокол некоей системы целиком. И тут начинает вылазить кривизна интерфейсов как типов:
2. "Вхождения" многих интерфейсов пересекаются, то бишь ф-ии/кортежи, составляющие интерфейсы, порой дублируют друг друга.
3. Интерфейсы служат тормозом к развитию. Для добавления новых членов в кортеж ф-ий, составляющих интерфейс, тупо создают новый IOldName2 или IOldNameEx и т.д., что не требуется в случае наличия необходимых "пинов".
И да. Никто тебе не запрещает делать "мета/пины", т.е. те, которые выдают как результат компоненты (кортежи других пинов). В общем, по мне проблема интерфейсов в КОП — в их уникальности, т.к. сейчас интерфейс равен типу в языке, что провоцирует на сильную связанность и дублирование содержимого интерфейсов. Нужна экземплярность.
Вот пример из электроники:
— многие пины у совершенно разных компонент совместимы друг с другом.
— когда речь о функциональности, то компонент целиком отвечает за функциональность (контракт на поведение). Т.е. реализация компонент разная, контракт один.
А что мы имеем сейчас? Сейчас контракт обслуживает сугубо интерфейсную (стыковочную) часть дизайна, а не поведенческую. То бишь, происходит ровно наоборот, под один и тот же интерфейс мы подставляем разные компоненты именно для целей разного их поведения. Ну дык! Давай те же перестанем делать вид, буд-то не понимаем этого, т.е. давайте оставим типизированный контракт сугубо для целей "стыковки" компонент, а не для целей управления семантикой... бо это ересь, т.к. компилятор не в состоянии контроллировать правильность семантики реализованного контракта. И чего тогда париться относительно "сложных" интерфейсов? Семантику пусть задают сами компоненты, а максимально простые интерфейсы пусть обеспечивают наименьшую связанность. Один метод в интерфейсе — меньше не бывает. ))
Еще пример разрыва в логике при реализации КОП сверху ООП: для того, чтобы вызвать совместимый с ранее известным некий сигнал (например, в электронике пусть будет тактовый сигнал), нам необходимо знать тип целого большого интерфейса!!! ОК, пусть система типов предлагает как вариант позвать еще один некий известный нам чуть более общий интерфейс ITactable... А что делать если у нас два тактовых входа? Ууупс???
AC>К тому же станет невозможно писать в ООП стиле, что сделает переход к компонентному программированию сложнее для программистов. V>>Поэтому модель контрактов современного ООП на реактивное программирование ни разу не ложится — слишком высока связанность для этого. AC>Раскрой пожалуйста мысль.
ИМХО, чем мощнее кортеж ф-ий, составляющих контракт, тем менее гибко его применение. Или раскрыть термин "высокая/низкая связанность"?
V>>Тут правильно сказали, что можно смотреть идеологию DirectShow. Что удобно в такой архитектуре — развязываются руки в относительно подключений компонент друг к другу. Почему? Из-за того, что кол-во сигналов обычно невелико, т.е., имея в базисе сигналы (т.е. ориентируя архитектуру на сигналы, вернее на топологию их прохождения), мы получаем очень и очень низкую связанность компонент при всё еще существующей типобезопасности. AC>Т.е. один пин должен мочь принимать несколько типов сигналов?
Нет, один пин обслуживает один тип сигнала. Просто не должно быть ограничений на конкретный тип этого сигнала.
Ну и синтаксис соединения и маппинга портов хотелось бы максимально простой:
component C1 {
in X : int;
var Z : int;
out Y : int = X * Z;
C1(z : int) : Z(z) {}
};
component C2 {
in X : int;
out Y : int;
var c1 : C1;
C2(z : int) : C1(z) {
X => c1.X;
c1.Y => Y;
}
};
component Main {
out Ya, Yb : int;
in X : int;
var a, b : C2;
Main() : a(42), b(43) {
X => a.X;
a.Y => Ya;
X => b.X;
b.Y => Yb;
}
}
===========
Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса...
Re[13]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Вот пример из электроники: V>- многие пины у совершенно разных компонент совместимы друг с другом. V>- когда речь о функциональности, то компонент целиком отвечает за функциональность (контракт на поведение). Т.е. реализация компонент разная, контракт один.
V>А что мы имеем сейчас? Сейчас контракт обслуживает сугубо интерфейсную (стыковочную) часть дизайна, а не поведенческую. То бишь, происходит ровно наоборот, под один и тот же интерфейс мы подставляем разные компоненты именно для целей разного их поведения. Ну дык! Давай те же перестанем делать вид, буд-то не понимаем этого, т.е. давайте оставим типизированный контракт сугубо для целей "стыковки" компонент, а не для целей управления семантикой... бо это ересь, т.к. компилятор не в состоянии контроллировать правильность семантики реализованного контракта. И чего тогда париться относительно "сложных" интерфейсов? Семантику пусть задают сами компоненты, а максимально простые интерфейсы пусть обеспечивают наименьшую связанность. Один метод в интерфейсе — меньше не бывает. ))
Хм, в таком случае "семантику" для компонента в целом задать будет нельзя. Нечто вроде утиной типизации выходит — если набор пинов у двух компонентов подходит, то они эквивалентны. Т.е. какой-нибудь вентиль с одним входом и одним выходом можно будет легко спутать с другим, по "смыслу" совершенно иным. Хотя хз, может это и не так страшно...
V>Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса...
Какие конфликты, например?
Re[13]: Заметка: Компонентная философия и реализация
V>Нужен всего один метод.
Т.е. взаимодействие через интерфейс может быть только однонаправленным? V>Это если смотреть на интерфейсы как на типы. А ты смотри на них как на экземпляры.
Т.е. компонент может создавать/разрушать свои интерфейсы? V>И тогда пусть их будет хоть сотни — это не мешает ни чему.
Анализ/отладка системы? V>1. Обычно интерфейсы не самодостаточны, а взаимодействуют со многими другими интерфейсами, если посмотреть на протокол некоей системы целиком. И тут начинает вылазить кривизна интерфейсов как типов:
Это баг старых вариантов КОП. V>2. "Вхождения" многих интерфейсов пересекаются, то бишь ф-ии/кортежи, составляющие интерфейсы, порой дублируют друг друга.
В смысле в одном интерфейсе или в нескольких интерфейсах одного компонента? V>3. Интерфейсы служат тормозом к развитию. Для добавления новых членов в кортеж ф-ий, составляющих интерфейс, тупо создают новый IOldName2 или IOldNameEx и т.д., что не требуется в случае наличия необходимых "пинов".
Т.е. расширение интерфейса компонента будет выполнятся за чёт добавление новых пинов? V>А что мы имеем сейчас? Сейчас контракт обслуживает сугубо интерфейсную (стыковочную) часть дизайна, а не поведенческую. То бишь, происходит ровно наоборот, под один и тот же интерфейс мы подставляем разные компоненты именно для целей разного их поведения. по идее(даже в том же COM'е) контракт должен включать не только соглашение о собственно интерфейсе, но и соглашение о семантике интерфейса, в т.ч. и том как дожен "вести" себя владелец интерфейса при взаимодействии через этот интерфейс. V>Один метод в интерфейсе — меньше не бывает. ))
В модели КОП из заметки, в интерфейсе может быть не одного метода, для случая когда нужно только установить факт подключения/отключения. V>Или раскрыть термин "высокая/низкая связанность"?
Да. V>Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса...
Интересно, опиши пожалуйста(лучше с картинками и комментированым псевдокодом), что из себя будет представлять компонент с пинами, каковы возможности пинов и, как будет выполнятся взаимодействие компонентов, в общих чертах.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[14]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали:
ARK>Хм, в таком случае "семантику" для компонента в целом задать будет нельзя.
Её и сейчас задать нельзя. Я потому и предлагаю не делать вид, будто можно.
Семантика пусть задается так, как она сейчас задаётся — вербально. В виде доки или ТЗ на компонент, например. )))
Ну и никто не мешает эти же пины представлять в виде типизированного "разъема", в этом случае "разъем" будет полным аналогом имеющегося на сегодня интерфейса/контракта. Каждый компонент в любом случае будет представлять из себя некий специфический разъем, просто из одних разъемов будет крайне удобно строить другие — в этом цель. Речь лишь о том, кто какие типы "видит". Например, в месте программы, где описывается порт-маппинг (т.е. соединение 2-х пинов), необходимо знать типы (разъемы) обоих компонент, без этого невозможно организовать типобезопасный код. Другое дело, что целевой пин мог придти транзитивно сколь угодно "далеко" через точно такой же порт-маппинг внутри описанных типов. Просто, помимо удобного синтаксиса "стыковки", удобным получается отуствие лишнего уровня косвенности по мере вложения компонент друг в друга. В электронике тоже простое прохождение сигнала по проводу пусть сквозь сколько угодно уровней абстракций дизайна ничего ведь не стоит... А в ООП сейчас стоит и очень некисло...
ARK>Нечто вроде утиной типизации выходит — если набор пинов у двух компонентов подходит, то они эквивалентны.
Да, один можно воткнуть вместо другого. В дотнете можно подать некий функтор (предикат, например) в огромное кол-во библиотечных методов. Надо лишь, чтобы этот функтор отвечал сигнатуре (считай — разъему). Но ведь кроме как коду функтора неизвестно, что этот он делает внутри. Я лишь предлагаю по такому принципу строить дизайн целиком, а не только отдельные библиотечные методы.
==========
Возвращаясь к утиной типизации — в ПО ситуация неплохая, в отличие от, ведь сами сигналы в ПО могут быть куда как более специализированы, чем в электронной области. Никто не мешает в виде сигнала использовать сколько угодно сложный пользовательский тип. Тут (повторюсь к посту рядом) было бы неплохо жестко отличать типы-компоненты от типов-данных. (Отдельная серьезная тема, но которая может потенциально разгрести часть бардака в современном ООП, где данные и объекты замешаны в одну кашу, и в итоге граф-"вычислитель" постоянно трансформируется в ходе работы, что лишает его детерминированности и возможности оптимизаций).
ARK>Т.е. какой-нибудь вентиль с одним входом и одним выходом можно будет легко спутать с другим, по "смыслу" совершенно иным. Хотя хз, может это и не так страшно...
Ес-но не страшно, т.к. у нас должна быть принципиальная возможность построения одних компонент из других.
V>>Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса... ARK>Какие конфликты, например?
Да хочется вообще минимализма, т.е. чтобы маппинг портов указывать не отдельно, как я показал, а прямо во время объявления пина/компонента. Ну и я так без фанатизма особо пока...
Стоит задача не столько реализовать некую готовую систему, сколько изобрести синтаксис, который самого удовлетворил бы. )) Компилятор-то потом в какой-нить мейнстримовый язык (или даже байт-код) написать не проблема.
Re[15]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Её и сейчас задать нельзя. Я потому и предлагаю не делать вид, будто можно. V>Семантика пусть задается так, как она сейчас задаётся — вербально. В виде доки или ТЗ на компонент, например. )))
В мейнстрим-языках нельзя, но в теории можно. Вон в Rust что-то там пытаются на практике сделать с typestate.
Кстати, я там выше спрашивал — в вашей модели, как я понимаю, компоненты принципиально без состояния (каждый выход — функция всех входов)? Т.е. понятие "последовательность вызовов" бессмысленно?
V>Ну и никто не мешает эти же пины представлять в виде типизированного "разъема", в этом случае "разъем" будет полным аналогом имеющегося на сегодня интерфейса/контракта.
Вот тут не очень понял, что выставляется наружу в виде портов — некий набор примитивных типов + можно выставлять другие компоненты?
V>Другое дело, что целевой пин мог придти транзитивно сколь угодно "далеко" через точно такой же порт-маппинг внутри описанных типов.
В смысле, выход внутреннего компонента "пробрасывается" напрямую на выход родительского?
V>Никто не мешает в виде сигнала использовать сколько угодно сложный пользовательский тип. Тут (повторюсь к посту рядом) было бы неплохо жестко отличать типы-компоненты от типов-данных.
Ну, данные наверное тоже можно считать примитивными "компонентами".
Подумал сейчас, возникла еще пара соображений.
Во-первых, "возмущение" по вашей системе, возникшее по сигналу извне, будет передаваться не мгновенно (как в теории), а за какое-то время. Что должно произойти, если реакция на прошлое возмущение еще не завершилась, а уже поступил новый сигнал? Завершаем все вычисления или прерываем и начинаем заново? В принципе, можно и так, и так сделать, наверное...
Во-вторых, как должно обстоять дело с обработкой ошибок? Предположим, в компоненте один из выходов задает функцию с ограниченной областью определения. Если функция на входных параметрах не определена, то что делаем? На один выход выставляем "еррор", а на другой — некое дефолтное значение результата? В таком случае можно и забыть проверить первый выход, получается аналог кодов возврата — ответственность на программисте. Либо как вариант — на выходе некий алгебраический тип данных Empty | Some a? Тут другой риск — эти нуллабельные типы будут пролезать во все интерфейсы и засорять их...
Во, и еще вопрос — как вы предполагаете избегать "коротких замыканий"? По идее можно ведь сделать цикл с кучей компонентов в цепочке и не заметить этого.
Re[16]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали:
V>>Её и сейчас задать нельзя. Я потому и предлагаю не делать вид, будто можно. V>>Семантика пусть задается так, как она сейчас задаётся — вербально. В виде доки или ТЗ на компонент, например. )))
ARK>В мейнстрим-языках нельзя, но в теории можно.
Да всё-равно не выйдет. Программа целиком и есть семантика.
ARK>Вон в Rust что-то там пытаются на практике сделать с typestate.
Я еще не смотрел, но почему-то уверен, что когда посмотрю, то за пару минут придумаю, как без проблем удовлетворить любой контракт, но при этом нарушить исходную семантику. ))
ARK>Кстати, я там выше спрашивал — в вашей модели, как я понимаю, компоненты принципиально без состояния (каждый выход — функция всех входов)? Т.е. понятие "последовательность вызовов" бессмысленно?
Это зависит от модели расрпостранения сигналов. Если синхронная модель — то последовательность вызовов имеет смысл. Если асинхронная, то тоже имеет, но уже по-другому (реакция лишь на изменения значения, а не на факт поступления 2-в-1-м — сигнала+события).
Я, вообще-то за то, чтобы компоненты могли (при надобности) иметь состояние.
Просто я считаю, что порядок в императиве можно навести только через иерархическу систему типов, где типы, отвечающие за поведение, имели бы фиксированную при создании (иммутабельную) структуру. Мутабельные пусть будут только данные. Я уже писал выше:
... бардака в современном ООП, где данные и объекты замешаны в одну кашу, и в итоге граф-"вычислитель" постоянно трансформируется в ходе работы, что лишает его детерминированности и возможности оптимизаций.
В электронике такое разделение происходит естественным образом — схема неизменна (до следующей перепрошивки, по крайней мере, если речь о матрице вентилей), но данные (сигналы + состояния ячеек памяти) — изменяемы.
Ну и еще такой момент в предложенной системе — отсутствие гонок. Не может два и более выхода работать на один вход. Иначе это КЗ и компилятор ругается. Скажем так, понять этот момент сразу будет сложновато... Это совсем другие навыки дизайна, чем принятые в ИП сегодня.
V>>Ну и никто не мешает эти же пины представлять в виде типизированного "разъема", в этом случае "разъем" будет полным аналогом имеющегося на сегодня интерфейса/контракта. ARK>Вот тут не очень понял, что выставляется наружу в виде портов — некий набор примитивных типов + можно выставлять другие компоненты?
Наружу выставляется кортеж пинов. Такой кортеж вполне себе тип.
Насчет выставлять другие компоненты как значения пинов — я соображения уже высказал: это путь к точно такому бардаку, который уже есть де-факто. Боюсь, без понятия "фабрики" не обойтись всё-равно, но использование фабрики весьма специфично — она используется только в момент создания "вычислителя".
V>>Другое дело, что целевой пин мог придти транзитивно сколь угодно "далеко" через точно такой же порт-маппинг внутри описанных типов. ARK>В смысле, выход внутреннего компонента "пробрасывается" напрямую на выход родительского?
"Пробрасывается" не значение, а сам пин в момент соединения компонент. Значение потом идёт напрямую от источника к приемнику, игнорируя уровни иерархии дизайна.
Это как делегирование подписывания на событие в дотнете:
Такое делегирование процедуры соединения пинов может быть сколько угодно глубоким... Но из-за объемистого и недекларативного синтаксиса на практике этим инструментом редко пользуются как основным инструментом дизайна (хотя он представляет из себя удобный трюк).
V>>Никто не мешает в виде сигнала использовать сколько угодно сложный пользовательский тип. Тут (повторюсь к посту рядом) было бы неплохо жестко отличать типы-компоненты от типов-данных. ARK>Ну, данные наверное тоже можно считать примитивными "компонентами".
Хотите об этом поговорить? Я бы с удовольствием. Тут самое время раскатать в блин понятие "ссылочного типа" и его зачастую некорректное применение к типам, отвечающим за данные. И всё потому, что компилятор позволяет что угодно.
ARK>Подумал сейчас, возникла еще пара соображений. ARK>Во-первых, "возмущение" по вашей системе, возникшее по сигналу извне, будет передаваться не мгновенно (как в теории), а за какое-то время. Что должно произойти, если реакция на прошлое возмущение еще не завершилась, а уже поступил новый сигнал? Завершаем все вычисления или прерываем и начинаем заново? В принципе, можно и так, и так сделать, наверное...
Всю схему "кто-то" должен пересчитывать. Этот кто-то должен раздавать компонентам вычислительные ресурсы. Принцип раздачи может быть очень разный.
Например: каждый пин будет содержать буфер-защелку. Когда на одном (любом) входе компонента будет обнаружено событие подачи сигнала, то компонент будет поставлен в очередь к шедуллеру. Когда до компонента дойдет очередь, то он может пересчитать свои выходы от всех измененных к моменту получения вычислительных ресурсов входов. В этом смысле логический вычислительный поток каждого компонента постоянно сидит в ожидании входных сигналов. Т.е. мы имеем строгую агентную среду, где не может быть гонок внутри компонент.
Логику можно усложнить. Например, реагировать не на факт подачи сигнала, а лишь на изменение входного значения. Если состояния такого автомата будут устойчивы, т.е. значение ф-ии переходов f(s, x) = s, то это будет асинхронный автомат. Кстати, нейронные сети с обратными связями так и работают — у них есть период затухания после возмущений. Как только сеть стабилизируется, т.е. войдет в устойчивое состояние, то вычисления закончены. Прямо отсюда должно быть понятно, как комбинировать программные модели синхронных и асинхронных автоматов. Сигнал об окончании вычислений асинхронного автомата может быть событием для зависимого синхронного.
Кстате, для эрудиции, базовый в схемотехнике RS-триггер — это классический асинхронный автомат, то бишь, автомат, выполненый на "чистых" функциях — логических вентилях. Просто в схеме есть обратные связи. Вот тебе откровение №1 — земля на самом деле круглая ячейка памяти — это чистая ф-ия + обратная связь. ))
Прямо отсюда должно быть понятно, почему я не сильно отличаю императивный и функциональный подход. Подобные устойчивые системы могут быть гораздо более сложными, чем RS-триггер. Могут состоять из кучи абсолютно чистых ф-ий, но при этом обладать изменяемым состоянием. Достаточно в ФП-программе суметь создать, например, циклическую структуру данных — и ву а ля, вот тебе изменяемое состояние из бесконечно считаемых по кругу ф-ий. Текущее устойчивое значение ф-ии на каждом витке вполне можно принять за состояние (как это есть в RS-триггере). Например, в упрощенном виде такая циклическая структура дана в виде монады IO в Хаскеле (при том, что её зацикливание выполняется внешним, по отношению к программе, вычислителем).
ARK>Во-вторых, как должно обстоять дело с обработкой ошибок?
В условиях детерминированной структуры вычислителя — проще простого. Ошибка — это состояние. Исключительных ситуаций не бывает (мы ведь не можем разрушть недостроенный дизайн). Если компонент может сигнализировать об ошибке — пусть у него будет под это специальный пин.
ARK>Предположим, в компоненте один из выходов задает функцию с ограниченной областью определения.
Если речь о зависимых типах, то мы просто не сможем подать на такой входной пин неподходящий выходной. Система типов не даст.
ARK>Во, и еще вопрос — как вы предполагаете избегать "коротких замыканий"? По идее можно ведь сделать цикл с кучей компонентов в цепочке и не заметить этого.
Это цикл, а не короткое замыкание. Короткое замыкание — это когда гонки. А цикл — это очень полезная структура. ))
Re[14]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
V>>Нужен всего один метод. AC>Т.е. взаимодействие через интерфейс может быть только однонаправленным?
1. даже если через каждый пин однонаправленно, то м/у компонентами может быть сколько-угодно-направленным:
A B
external
function
----+ +-------+
| | |
arg >---> x |
| | |
res <---< y=x^2 |
| | |
----+ +-------+
2. ПО гибче, чем схемотехника: сигнатура метода пина может возвращать значение, то бишь нарисованные 2 пина могут быть заменены одним, функциональным. (Кстате, в ФП другого способа-то и нет, т.к. непосредственные циклические подключения компонент невозможны).
В примере компонент B — это внешний функциональный преобразователь для A. Но! Обратное тоже верно!!! Однако, в ФП функцией может быть только кто-то один из них, т.е. никакой тебе симметричности. )))
Потому что только poll схема вычислений, а реактивнй подход это push.
А в теле самих компонент ес-но удобно писать на каком-нить языке по свойствам близком к мейнстриму, используя обычные ф-ии.
V>>Это если смотреть на интерфейсы как на типы. А ты смотри на них как на экземпляры. AC>Т.е. компонент может создавать/разрушать свои интерфейсы?
В эту область можно порассуждать, но я уже предлагал сделать графы объектов иммутабельными, а мутабельными оставить только данные.
V>>И тогда пусть их будет хоть сотни — это не мешает ни чему. AC>Анализ/отладка системы?
Проще, чем в современном ООП, ведь внутри каждого компонента нет гонок как во время теста, так и во время работы.
V>>1. Обычно интерфейсы не самодостаточны, а взаимодействуют со многими другими интерфейсами, если посмотреть на протокол некоей системы целиком. И тут начинает вылазить кривизна интерфейсов как типов: AC>Это баг старых вариантов КОП. V>>2. "Вхождения" многих интерфейсов пересекаются, то бишь ф-ии/кортежи, составляющие интерфейсы, порой дублируют друг друга. AC>В смысле в одном интерфейсе или в нескольких интерфейсах одного компонента?
В нескольких интерфейсах, относящихся к одной подсистеме.
V>>3. Интерфейсы служат тормозом к развитию. Для добавления новых членов в кортеж ф-ий, составляющих интерфейс, тупо создают новый IOldName2 или IOldNameEx и т.д., что не требуется в случае наличия необходимых "пинов". AC>Т.е. расширение интерфейса компонента будет выполнятся за чёт добавление новых пинов?
Мммм... не будет никакого расширения интефейса. Отдельный пин нерасширяем и несужаем.
V>>А что мы имеем сейчас? Сейчас контракт обслуживает сугубо интерфейсную (стыковочную) часть дизайна, а не поведенческую. То бишь, происходит ровно наоборот, под один и тот же интерфейс мы подставляем разные компоненты именно для целей разного их поведения. AC> по идее(даже в том же COM'е) контракт должен включать не только соглашение о собственно интерфейсе, но и соглашение о семантике интерфейса, в т.ч. и том как дожен "вести" себя владелец интерфейса при взаимодействии через этот интерфейс.
Ну и как себя должен вести стандартный вывод, перенаправленный в nul? На принтер? В сокет?
Вот так же и с пинами.
V>>Один метод в интерфейсе — меньше не бывает. )) AC>В модели КОП из заметки, в интерфейсе может быть не одного метода, для случая когда нужно только установить факт подключения/отключения.
Непонятна практическая польза от этого. Сейчас пустые интерфейсы используются как иммутабельные поля типа bool. Т.е., идёт дублирование языковых ср-в. В дотнете есть еще 3-й аналогичный вариант — аатрибуты.
V>>Или раскрыть термин "высокая/низкая связанность"? AC>Да.
При низкой связанности дизайн построен на небольшом кол-ве "всем известных типов". Низкая связанность означает гибкость, ведь для замены элемента новым, этот новый должен знать лишь об общих типах, а не о конкретных. Если же компоненты полагаются на знание конкретики друг о друге — то это высокая связанность. Если в системе полно уникальных интерфейсов (как раз по 1-му на компонент или около того) — то вот пример сильной связанности.
V>>Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса... AC>Интересно, опиши пожалуйста(лучше с картинками и комментированым псевдокодом), что из себя будет представлять компонент с пинами, каковы возможности пинов и, как будет выполнятся взаимодействие компонентов, в общих чертах.
Э нет, это слишком надолго.
Исходная задача — собирать из "кубиков" сложные алгоритмы обработки сигналов (звука). Про варианты взаимодействия рядом написал тебе же.
Когда-то паял примочки к гитарам, потом стал экспериментировать программно: http://www.rsdn.ru/forum/alg/3793843.1
Здравствуйте, vdimas, Вы писали:
V>Да всё-равно не выйдет. Программа целиком и есть семантика.
Почему же, в ограниченном диапазоне — вполне выйдет. Design by contract, особенно статический — это же мега-круто.
Ну а семантику прям всей программы рассматривать, ИМХО, не стоит.
V>Я еще не смотрел, но почему-то уверен, что когда посмотрю, то за пару минут придумаю, как без проблем удовлетворить любой контракт, но при этом нарушить исходную семантику. ))
Не сомневаюсь. Но в любом случае, чем больше проверок — тем лучше.
ARK>>Кстати, я там выше спрашивал — в вашей модели, как я понимаю, компоненты принципиально без состояния (каждый выход — функция всех входов)? Т.е. понятие "последовательность вызовов" бессмысленно?
V>Это зависит от модели расрпостранения сигналов. Если синхронная модель — то последовательность вызовов имеет смысл. Если асинхронная, то тоже имеет, но уже по-другому (реакция лишь на изменения значения, а не на факт поступления 2-в-1-м — сигнала+события).
Так. Как я понимаю, это в программе будет выглядеть примерно таким образом — в теле какой-то функции мы должны дергать выходы компонента в определенном порядке (так же, как в императивном программировании — сперва открываем файл, потом читаем из него). Контракты совсем бы не помешали, чтобы проконтролировать это (сперва читай этот выход, потом этот).
V>Я, вообще-то за то, чтобы компоненты могли (при надобности) иметь состояние.
Тогда внутри компонента с состоянием будет куча локов-синхронизаций?
V>Наружу выставляется кортеж пинов. Такой кортеж вполне себе тип. V>Насчет выставлять другие компоненты как значения пинов — я соображения уже высказал: это путь к точно такому бардаку, который уже есть де-факто. Боюсь, без понятия "фабрики" не обойтись всё-равно, но использование фабрики весьма специфично — она используется только в момент создания "вычислителя".
Т.е. вы определяете в своей модели набор примитивных типов (ну и один структурный примитив "кортеж").
V>"Пробрасывается" не значение, а сам пин в момент соединения компонент. Значение потом идёт напрямую от источника к приемнику, игнорируя уровни иерархии дизайна.
Ну да, я так и понял. ИМХО, концептуально может быть и копирование значения (если это упрощает модель). А на деле копирование убирается компилятором.
ARK>>Ну, данные наверное тоже можно считать примитивными "компонентами". V>Хотите об этом поговорить? Я бы с удовольствием. Тут самое время раскатать в блин понятие "ссылочного типа" и его зачастую некорректное применение к типам, отвечающим за данные. И всё потому, что компилятор позволяет что угодно.
Я лично считаю, что ссылочные типы не нужны.
V>Всю схему "кто-то" должен пересчитывать. Этот кто-то должен раздавать компонентам вычислительные ресурсы. Принцип раздачи может быть очень разный. V>Например: каждый пин будет содержать буфер-защелку. Когда на одном (любом) входе компонента будет обнаружено событие подачи сигнала, то компонент будет поставлен в очередь к шедуллеру. Когда до компонента дойдет очередь, то он может пересчитать свои выходы от всех измененных к моменту получения вычислительных ресурсов входов. В этом смысле логический вычислительный поток каждого компонента постоянно сидит в ожидании входных сигналов. Т.е. мы имеем строгую агентную среду, где не может быть гонок внутри компонент.
Вопрос только — что будет, если пересчитать не успели, а пришел новый сигнал? В теории можно обрубить вычисления, если результатом их не предполагается побочного эффекта. Только будет ли компилятор достаточно умен, чтобы отслеживать такие вещи...
V>Логику можно усложнить. Например, реагировать не на факт подачи сигнала, а лишь на изменение входного значения.
ИМХО, имеет смысл реагировать только на изменение — во всех случаях.
V>Кстате, для эрудиции, базовый в схемотехнике RS-триггер — это классический асинхронный автомат, то бишь, автомат, выполненый на "чистых" функциях — логических вентилях.
Да, кое-что слышал об этом.
V>Прямо отсюда должно быть понятно, почему я не сильно отличаю императивный и функциональный подход. Подобные устойчивые системы могут быть гораздо более сложными, чем RS-триггер. Могут состоять из кучи абсолютно чистых ф-ий, но при этом обладать изменяемым состоянием. Достаточно в ФП-программе суметь создать, например, циклическую структуру данных — и ву а ля, вот тебе изменяемое состояние из бесконечно считаемых по кругу ф-ий. Текущее устойчивое значение ф-ии на каждом витке вполне можно принять за состояние (как это есть в RS-триггере). Например, в упрощенном виде такая циклическая структура дана в виде монады IO в Хаскеле (при том, что её зацикливание выполняется внешним, по отношению к программе, вычислителем).
Тут уже появляется новая сущность — некое "устойчивое состояние" системы. ИМХО, это сильно усложняет понимание программы.
V>Если компонент может сигнализировать об ошибке — пусть у него будет под это специальный пин.
А если мы забудем поверить этот специальный пин?
V>Если речь о зависимых типах, то мы просто не сможем подать на такой входной пин неподходящий выходной. Система типов не даст.
Вот это интересный момент. Как вы себе это представляете? Это же те самые контракты.
V>Это цикл, а не короткое замыкание. Короткое замыкание — это когда гонки. А цикл — это очень полезная структура. ))
Ну окей, пусть цикл. По-моему, возможность зацикливания надо бы устранить, нет?
Re[10]: Заметка: Компонентная философия и реализация
V>>Не совсем. Это семантический эквивалент на механику вокруг IConnectionPoint/IConnectionPointContainer AVK>По заявлениям ТС, реактивность не есть обязательный признак. Так что нет.
Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова, точно так же как листенеры в джаве или как IConnectionPoint/IConnectionPointContainer в COM. Или как ты привел пример с IObservable.
V>>, а так же их IDispatch-эквивалент. Это аналог джавовских листенеров событий. Всё это "красиво" встроено в язык VB/VBA, но в С++, Джаве и дотнете аналогичное только ручками. AVK>Аналогичное что?
Аналогичное по механике соединение компонент через обмен интерфейсами обратного вызова. На сегодня только ручками в ООП-языках, кроме VB/VBA/VBS.
AVK>С шарпе IConnectionPoint превращается в обыкновенное событие.
Мммм... каждое событие в шарпе — независимо. Поэтому подписывание на интерфейс обратного вызова происходит поэлементно через делегаты, эдакие указатели на методы, нарушающие ООП-типизированность контрактов обратного вызова. Сравни с джавой, где ты обязан подписаться на контракт обратного вызова целиком, а не только на его часть. Да, я понимаю, что базовые листенеры событий представляют из себя "пустышки"... но тем не менее, они отвечают контракту. Эдак удовлетворение любого обычного интерфейса можно сделать через пустышки и превратить строго-типизированные контракты в россыпь независимых методов, каждый из которых можно реализовать отдельно. Собсно, я именно так и предлагаю поступить с обычными ООП-контрактами в моей модели. Ведь именно так поступили с контрактами обратного вызова в дотнете и никто не парится по этому поводу.
AVK>При желании можно завернуть в IObservable.
Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП. Смотри, насколько коряво выходит в ООП-синтаксисе без поддержки языка.
V>>Дык, реактивность требует некоторой поддержки AVK>Какой?
Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга и обязательного низлежащего "вычислителя-шедуллера", потому как сейчас без слез на эту кашу вокруг тривиальных вещей смотреть невозможно:
В желаемой некоей реактивной (или агентной в ООП-координатах) среде должен быть только первый метод, который ведет себя как второй:
component C1 {
in param : string;
out result : DataType =
{ // LongRunningOperation depending on param
...
};
}
Или взять ручное заворачивание событий в C# для целей сохранения строгой типизации:
// To consume GenericEvent as an IObservable:
IObservable<IEvent<SomeEventArgs>> eventAsObservable = Observable.FromEvent<SomeEventArgs>(
ev => GenericEvent += ev,
ev => GenericEvent -= ev);
Сорри, но это хи-хи. Это роспись в том, что C# как язык не приспособлен для целей "настоящего" компонентного программирования (когда программа действительно составляется из "кубиков"-компонент в декларативной манере).
Вот зачем нужен отдельный язык — чтобы подобное шло изкаробки.
=============
Так-то я крайне положительно отношусь к Rx — это ведь постепенная наработка понимания, что нужно современному сложному ПО... хотя лично я, как программист, не готов работать в столь убогой манере, как предлагается в Rx. Просто рано или поздно "кол-во понимания проблемы" должно перерасти в кач-во и тоже самое станет возможно в человеческом виде.
Re[11]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова
Автор прямо и недвусмысленно это опроверг.
V>Аналогичное по механике соединение компонент через обмен интерфейсами обратного вызова. На сегодня только ручками в ООП-языках, кроме VB/VBA/VBS.
Все равно непонятно — чем VB в этом плане лучше шарпа. Тем что подписку на события можно в декларации описать? Это все?
V>Мммм... каждое событие в шарпе — независимо.
А что такое зависимые события и зачем они нужны?
V>Сравни с джавой, где ты обязан подписаться на контракт обратного вызова целиком
Я на джаве в свое время пописал достаточно. Дотнетные события удобнее. А IObservable еще удобнее.
V>, а не только на его часть. Да, я понимаю, что базовые листенеры событий представляют из себя "пустышки"... но тем не менее, они отвечают контракту.
Делегат дотнетный это тоже вполне себе строго типизированный контракт. Как и IObservable.
V> Эдак удовлетворение любого обычного интерфейса можно сделать через пустышки и превратить строго-типизированные контракты в россыпь независимых методов
Вот только колбек это не то же самое, что прямой метод. Но даже если тебе сильно хочется по непонятной причине набор событий оформить в виде единого контракта — на базе того же IObservable это сделать совсем несложно.
V>Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП.
IObservable это реализация паттерна publisher-subscriber. Не меньше и не больше.
V>Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга
Зачем?
V> и обязательного низлежащего "вычислителя-шедуллера"
Шедулеры прекрасно реализованы в Rx без какой либо поддержки языка. Я тебе больше скажу — на прямой вопрос Эрику Мейеру, какая поддержка для Rx может быть добавлена в C#, он ответил прямо и недвусмысленно — никакая не нужна.
V>Или взять ручное заворачивание событий в C# для целей сохранения строгой типизации:
Ручное заворачивание нужно только для совместимости со старым кодом.
V>Сорри, но это хи-хи. Это роспись в том, что C# как язык не приспособлен для целей "настоящего" компонентного программирования
Скорее он не приспособлен для странного конструкта, который ты сочинил.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
V>>Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова AVK>Автор прямо и недвусмысленно это опроверг.
С точки зрения экспортирующего компонента, это таки подача интерфейсов обратного вызова, на подобии Action Listener'ов из Java.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[13]: Заметка: Компонентная философия и реализация
AC>>С точки зрения экспортирующего компонента, это таки подача интерфейсов обратного вызова AVK>Тогда реактивное программирование в твоей модели становится обязательным, что ты прямо опровергал.
Как связано реактивное программирование с cellback'ами?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[15]: Заметка: Компонентная философия и реализация
AC>>Как связано реактивное программирование с cellback'ами? AVK>Когда основные связи в программе у тебя строятся не прямыми вызовами, а колбеками, это самое настоящее реактивное программирование и есть.
Ты читал определение из википедии , потому что, именно это я подразумеваю под "реактивное программирование".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[17]: Заметка: Компонентная философия и реализация
AC>>Ты читал определение из википедии AVK>Я то читал. Ты лучше попробуй его осмыслить.
Насколько я осмыслил, там о потоках данных, безотносительно реализации(на калбеках, не на калбеках не существенно).
У тебя есть другой вариант?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[19]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AVK>>Я то читал. Ты лучше попробуй его осмыслить. AC>Насколько я осмыслил, там о потоках данных
А у тебя как предполагается — программы без потоков данных что ли?
И реактивное программирование это не просто про поток данных. Ты на сам термин посмотри — реактивное означает реакцию. Т.е. данные меняются, программа реагирует. И если у тебя все публичные контракты — коллбеки, значит ты вынужден будешь строить программу в соответствии с заветами реактивного программирования — описывать реакцию на какое то входное воздействие.
AC>У тебя есть другой вариант?
У меня тот же. Я вот только не пойму что ты подразумеваешь под потоками данных. К примеру, поток координат и нажатий кнопок от мыша — это поток данных или нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
AC>>Насколько я осмыслил, там о потоках данных AVK>А у тебя как предполагается — программы без потоков данных что ли?
С, конечно же. AVK>И реактивное программирование это не просто про поток данных. Ты на сам термин посмотри — реактивное означает реакцию.
Тут ты прав, да. Но, реакция != вызов callback'а. AVK>Т.е. данные меняются, программа реагирует. И если у тебя все публичные контракты — коллбеки, значит ты вынужден будешь строить программу в соответствии с заветами реактивного программирования — описывать реакцию на какое то входное воздействие.
У меня есть и поля(забегая немного вперёд — у меня, интерфейсы(публичные контракты) состоят только из полей, а методы это поля функционального типа(которым могут присваиваться функции)). AVK>У меня тот же. Я вот только не пойму что ты подразумеваешь под потоками данных. К примеру, поток координат и нажатий кнопок от мыша — это поток данных или нет?
Да, это поток данных(а точнее сообщений), извлекаемых main thread'ом из очереди, в цикле без callback'ов.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[16]: Заметка: Компонентная философия и реализация
Здравствуйте, AndrewVK, Вы писали:
AC>>Как связано реактивное программирование с cellback'ами? AVK>Когда основные связи в программе у тебя строятся не прямыми вызовами, а колбеками, это самое настоящее реактивное программирование и есть.
Скорее вопрос токи зрения. Вызов интерфейсов обратного вызова — это же обычный вызов, как интерфейсов прямого. Отличия лишь в том, что компонент не реализует целевой контракт, а требует от других. Как раз в предложенной схеме такое требование.
Re[12]: Заметка: Компонентная философия и реализация
Здравствуйте, AndrewVK, Вы писали:
V>>Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова AVK>Автор прямо и недвусмысленно это опроверг.
Не обратил внимания. Если это так — то автор ошибся.
V>>Аналогичное по механике соединение компонент через обмен интерфейсами обратного вызова. На сегодня только ручками в ООП-языках, кроме VB/VBA/VBS. AVK>Все равно непонятно — чем VB в этом плане лучше шарпа. Тем что подписку на события можно в декларации описать? Это все?
— нет ручного создание объектов, реализующих интерфейс обратного вызова;
— нет ручной подписки.
V>>Мммм... каждое событие в шарпе — независимо. AVK>А что такое зависимые события и зачем они нужны?
Тоже, что и зависимые методы в интерфейсах. Для полноты некоего протокола.
V>>Сравни с джавой, где ты обязан подписаться на контракт обратного вызова целиком AVK>Я на джаве в свое время пописал достаточно. Дотнетные события удобнее. А IObservable еще удобнее.
В джаве как раз схема событий в точности как IObservable. Просто с делегами и событиями в дотнете выходит проще заворачивать "обычные" классы в IObservable для последующего пользования методов-расширений Rx.
V>> Эдак удовлетворение любого обычного интерфейса можно сделать через пустышки и превратить строго-типизированные контракты в россыпь независимых методов AVK>Вот только колбек это не то же самое, что прямой метод.
Зато вызов метода колбека в точности тоже самое.
V>>Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП. AVK>IObservable это реализация паттерна publisher-subscriber. Не меньше и не больше.
Он же паттер Observer. Масло-маслянное, не меньше и не больше.
Но мой фокус не на том, что в классике Observer — это превращение обычных колбеков из singlecast в multicast, а в том, что речь таки о колбеках, то бишь о событийной модели. А мультикастнос-механизм можно рассматривать как некий внешний прокси для компонента (обычный mediator), чтобы сам компонент не нагружать фнукциональностью мультикаста (как это сейчас сделано в событиях дотнета).
V>>Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга AVK>Зачем?
Для целей читабельности.
V>> и обязательного низлежащего "вычислителя-шедуллера" AVK>Шедулеры прекрасно реализованы в Rx без какой либо поддержки языка.
На простейший чих много приседаний. Примеры уже привел.
AVK>Я тебе больше скажу — на прямой вопрос Эрику Мейеру, какая поддержка для Rx может быть добавлена в C#, он ответил прямо и недвусмысленно — никакая не нужна.
Это лишь значит, что C# позиционируют не для агентного/реактивного программирования, а для традиционного ООП.
V>>Или взять ручное заворачивание событий в C# для целей сохранения строгой типизации: AVK>Ручное заворачивание нужно только для совместимости со старым кодом.
И новым тоже. Код на традиционных событиях более повторно-применим, чем специализированный для Rx.
V>>Сорри, но это хи-хи. Это роспись в том, что C# как язык не приспособлен для целей "настоящего" компонентного программирования AVK>Скорее он не приспособлен для странного конструкта, который ты сочинил.
В чем странность? ИМХО, агентное и реактивное программирование имеют много общего. Скажем так, первое базируется на втором, только отличается более развитой поддержкой политик доставки сообщений (событий).
Re[17]: Заметка: Компонентная философия и реализация
Здравствуйте, vdimas, Вы писали:
V>Скорее вопрос токи зрения.
Да ради бога. Все это сводится к спору о терминах. Важно другое — предлагаемое жестко ограничивает направление взаимодействия колбеками и активными компонентами (ничего не напоминает?). В то время как существующие модели такого ограничения не вносят. Хочешь прямого проталкивания данных — пользуешься IEnumerable, хочешь обратного — переходишь на IObservable.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, vdimas, Вы писали:
AVK>>Я на джаве в свое время пописал достаточно. Дотнетные события удобнее. А IObservable еще удобнее. V>В джаве как раз схема событий в точности как IObservable.
Еще бы, паттерн то один и тот же. Джава просто не позволяет обеспечить приемлемый синтаксис. С# 3+ позволяет, хоть и не идеален.
V>>>Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП. AVK>>IObservable это реализация паттерна publisher-subscriber. Не меньше и не больше. V>Он же паттер Observer. Масло-маслянное, не меньше и не больше.
Соответственно не надо сочинять новых сущностей и запутывать.
V>>>Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга AVK>>Зачем?
V>Для целей читабельности.
Мне лично не кажется вариант VB более читабельным.
AVK>>Шедулеры прекрасно реализованы в Rx без какой либо поддержки языка.
V>На простейший чих много приседаний. Примеры уже привел.
Это бестолковый пример.
AVK>>Я тебе больше скажу — на прямой вопрос Эрику Мейеру, какая поддержка для Rx может быть добавлена в C#, он ответил прямо и недвусмысленно — никакая не нужна. V>Это лишь значит, что C# позиционируют не для агентного/реактивного программирования, а для традиционного ООП.
Эрик вообще никак не позиционирует С#, ты не с того конца смотришь.
AVK>>Ручное заворачивание нужно только для совместимости со старым кодом. V>И новым тоже.
Нет, с новым не нужно.
V> Код на традиционных событиях более повторно-применим, чем специализированный для Rx.
Спорно. Единственная серьезная проблема — существующие дизайнеры UI его не умеют искаропки.
V>В чем странность?
В том, что ты с упоением описываешь свои идеи, но совершенно ничего не говоришь о том, какие бенефиты мы получаем на реальных задачах.
V> ИМХО, агентное и реактивное программирование имеют много общего.
Агентное программирование — разновидность реактивного. Только речь то не о реактивном программировании как парадигме, а твоих идеях по созданию зависимых событий.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Из реальной всамделишной практики: Серсвисно-Ориентированные Архитектуры (SOA) имеют громадное преимущество над просто ООП за счет:
1) Активной реакции сервиса на подключение
2) Сокрытия реализации сервиса за интерфейсом
Re[14]: Заметка: Компонентная философия и реализация
Здравствуйте, AndrewVK, Вы писали:
AVK>В том, что ты с упоением описываешь свои идеи, но совершенно ничего не говоришь о том, какие бенефиты мы получаем на реальных задачах.
Идея простая — попытка приспособить философию реактивного программирования под объекты. Для этого будет удобно разбивать интерфейсы на независимые вхождения. Любой метод для вызова- пусть будет входной пин, под который не нужен адаптер-делегат, как это есть сейчас. ИМХО, требуется легкость связывания, т.к. в реактивном программировании мы пляшем от топологии, то бишь связей много, связи первичны, вокруг них всё.
По ссылке я критиковал имеющийся на тот момент биндинг в дотнете, предлагая явную типизированную схему вместо неявных соглашений биндинга ComponentModel. Бенефиты такие же, как от Rx — это полудекларативное построение "топологии" распространения событий. Т.к. у меня речь об обработке сигналов, то дополнительный бенефит абстракции "пинов" в том, чтобы эти пины игнорировали добавочную косвенность, обычно возникающую в случае многих слоёв иерархии, т.е., чтобы их можно было протаскивать непосредственно от источника события к приемнику через все абстракции. В остальном — ничего такого, что не лежало бы на поверхности.
Еще момент — я в своих разработках выношу мультикаст как отдельный элемент. Вот почему стараюсь не заостряться на паттерне Observer, бо я вижу Observer как всего-навсего multicast callback. У меня в топологию вставляется промежуточный элемент, превращающий singlecast в multicast, явным образом и только там, где действительно должно быть несколько получателей у исходного события (это единицы %% от всех связей в реальном применении). Какой здесь бенефит? — да всего лишь экономия на еще одном уровне косвенности на выходе каждого компонента и заметно меньше затрат на сам вызов. В средней моей схеме порядка нескольких сотен базовых компонент (суммарно по всем компонентам более высокого уровня), т.е. как бэ этот момент актуален на 96/192кГц тактовой (передискретизация в 2/4 раза).
Ну и говорил уже, что если у события всего один метод, то вместо таблицы виртуальных ф-ий нужен просто адрес ф-ии (я экспериментирую на плюсах), т.е. еще раз уменьшение косвенности. Т.е. куда ни плюнь, но всего один метод в калбеке — это удобно.
Тебе именно потому IObserver удобнее Джавы, что он обслуживает ровно один метод, через одну генерик-абстракцию OnNext(T value), где T — это тип-заменитель аргумента(ов) аналогичного метода. В итоге получается гибко, т.к. можно построить генерик-фреймворк всего над парой базовых генерик-интерфейсов. Т.е., со своей идеей разбиения контрактов на независимые "пины" я таки угадал. ))
V>> ИМХО, агентное и реактивное программирование имеют много общего. AVK>Агентное программирование — разновидность реактивного.
Всей разницы, что в агентном программировании события могут накапливаться и обрабатываться в отложенной манере. Например, в дополнении к моему multicast-proxy добавляешь всевозмжные async-queue-proxy с разными политиками и ву а ля (как раз по работе только что аналогичное прикрутил для системы логгирования). А набор интерфейсов всё тот же...
AVK>Только речь то не о реактивном программировании как парадигме, а твоих идеях по созданию зависимых событий.
Зависимые события — это не мои идеи. Это то, что было в COM, Java и то, что предлагает автор топика. Я, наоборот, настаиваю на разбиении кортежей методов на независимые "пины" для удобства оперирования топологией связей.
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, borisman3, Вы писали:
B>Из реальной всамделишной практики: Серсвисно-Ориентированные Архитектуры (SOA) имеют громадное преимущество над просто ООП за счет: B>1) Активной реакции сервиса на подключение B>2) Сокрытия реализации сервиса за интерфейсом
Круто. Вот только п.1 ООП перпендикулярен, а п.2 — один из базовых принципов ООП.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, borisman3, Вы писали:
B>>Из реальной всамделишной практики: Серсвисно-Ориентированные Архитектуры (SOA) имеют громадное преимущество над просто ООП за счет: B>>1) Активной реакции сервиса на подключение B>>2) Сокрытия реализации сервиса за интерфейсом
AVK>Круто. Вот только п.1 ООП перпендикулярен, а п.2 — один из базовых принципов ООП.
Да, к сожалению тут мы говорим об одной штуке(SOA) реализованной поверх другой штуки (ООП) и потому трудно понять что-ж это я имел в виду. Поясню.
1) ооп
IMyService s = new MyService();
2) SOA
IMyService s = serviceDiscovery.requireService(IMyService.class);
Первый вариант намертво закрепляет реализацию в компайл-тайме, второй — позволяет ее менять в рантайме. Ну и дальше понятно. Конечно Вы можете сказать что мол вариант 1) это не ООП, что в хорошей ООП программе надо делать по другому и т.д. и т.п. Заранее соглашаюсь, все так. И один из способов в ООП программе сделать все как надо — это SOA.
Re[4]: Заметка: Компонентная философия и реализация
Здравствуйте, borisman3, Вы писали:
B>Да, к сожалению тут мы говорим об одной штуке(SOA) реализованной поверх другой штуки (ООП) и потому трудно понять что-ж это я имел в виду. Поясню.
B>1) ооп B>IMyService s = new MyService();
B>2) SOA B>IMyService s = serviceDiscovery.requireService(IMyService.class);
Ужась. Пункт 2 в ООП называется абстрактная фабрика, а точнее паттерн service locator. И, кстати, к SOA вообще никакого отношения не имеет.анет.
B>Первый вариант намертво закрепляет реализацию в компайл-тайме, второй — позволяет ее менять в рантайме.
Ага. Один из основных принципов ООП.
B>что в хорошей ООП программе надо делать по другому и т.д. и т.п. Заранее соглашаюсь, все так. И один из способов в ООП программе сделать все как надо — это SOA.
SOA совсем о другом. Основное отличие SOA от внутрипрограммного ООП состоит в отсутствии навигационного доступа. Т.е. в SOA нельзя из метода возвращать полноценные объекты, у которых удаленно можно позвать свои методы. Эта специфика связана с тем, что такое плохо работает в распределенных системах. А способ создания экземпляра класса по контракту никакого отношения к SOA не имеет.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AlexRK, Вы писали:
V>>Да всё-равно не выйдет. Программа целиком и есть семантика. ARK>Почему же, в ограниченном диапазоне — вполне выйдет. Design by contract, особенно статический — это же мега-круто.
Почти весь этот design by contract можно вложить в систему типов хотя бы С++ еще аж прошлого стандарта безо-всякого abstraction penalty. То бишь, это всё костыли для недостаточно выразительных систем типов в координатах лямбда-куба. В системах можно выразить вообще весь design by contract. С++ относится к системе типов Лw.
В любом случае, я бы не стал ограничения на входные и выходные данные приравнивать к семантике.
ARK>Ну а семантику прям всей программы рассматривать, ИМХО, не стоит.
Ну ОК, тогда не стоит пользоваться термином "семантика" для описания того, что же нам гарантируют типизированные интерфейсы. Собсно, об этом я и говорил.
V>>Я еще не смотрел, но почему-то уверен, что когда посмотрю, то за пару минут придумаю, как без проблем удовлетворить любой контракт, но при этом нарушить исходную семантику. )) ARK>Не сомневаюсь. Но в любом случае, чем больше проверок — тем лучше.
Ага, т.е. чем "жирнее" интерфейс, тем меньше вероятность его "случайной" реализации, не?
Я примерно так себе и представляю причину, почему идея разбить кортеж ф-ий контракта на относительно независимые сигналы встречает инстинктивное сопротивление (не ты первый). Ведь кортеж — уже некое ограничение само по себе.
V>>Это зависит от модели расрпостранения сигналов. Если синхронная модель — то последовательность вызовов имеет смысл. Если асинхронная, то тоже имеет, но уже по-другому (реакция лишь на изменения значения, а не на факт поступления 2-в-1-м — сигнала+события). ARK>Так. Как я понимаю, это в программе будет выглядеть примерно таким образом — в теле какой-то функции мы должны дергать выходы компонента в определенном порядке (так же, как в императивном программировании — сперва открываем файл, потом читаем из него). Контракты совсем бы не помешали, чтобы проконтролировать это (сперва читай этот выход, потом этот).
Боюсь, лучшим выходом здесь будут не контракты, предписывающие что в каком порядке дергать, а декларативность. Угу, в сочетании с изменяемым состоянием. Необходимо описать реакцию на входное воздействие. Т.к. низлежащий вычислитель будет гарантировать отсутствие гонок, то эта реакция вполне может пользоваться персистентными данными (сохраняемыми от вызова к вызову). Поэтому становится возможным реализовать, например, рекурсивный цифровой фильтр:
И вообще любой классический автомат, который имеет конечное время реакции на воздействие.
V>>Я, вообще-то за то, чтобы компоненты могли (при надобности) иметь состояние. ARK>Тогда внутри компонента с состоянием будет куча локов-синхронизаций?
Не внутри, а снаружи. Синхронизация в пользовательском коде — самый быстрый путь к дедлокам. ))
Я уже не говорю о провальной получаемой эффективности, если решать вопросы синхронизации "по-месту" и таких мест набирается немеряно.
ARK>Т.е. вы определяете в своей модели набор примитивных типов (ну и один структурный примитив "кортеж").
Типы — ес-но. Просто хотел бы иметь некую иерархию типов: данные отдельно, "вычислители" — отдельно. И разные правила для разных сортов типов.
V>>"Пробрасывается" не значение, а сам пин в момент соединения компонент. Значение потом идёт напрямую от источника к приемнику, игнорируя уровни иерархии дизайна. ARK>Ну да, я так и понял. ИМХО, концептуально может быть и копирование значения (если это упрощает модель). А на деле копирование убирается компилятором.
Копирование компилятором не убирается, потому что его просто нет. )))
Сфокусируйся, плиз: выходной пин сигнального типа — это точка для подачи callback-листенера (см. IObservable, например), то бишь некое входное проперти/метод с т.з. "традиционного" ООП. Наоборот, входной пин — это выходное проперти, которое возвращает экземпляр листенера. Так вот, входной пин компонента на сколь угодно глубоком уровне иерархии можно протащить куда угодно наверх и затем обратно куда угодно в глубь другой иерархии. Такое протаскивание выполняется только в момент построения топологии схемы, а затем сигналы идут непосредственно от источника к приемнику.
В общем, сегодня за привычные ООП иерархии мы расплачиваемся эффективностью и действительно полагаемся на компилятор. Вот меня всегда жаба и давила, что электронщики за иерархии ничем не расплачиваются. Ведь все иерархии — они сугубо умозрительные на стадии дизайна.
ARK>Я лично считаю, что ссылочные типы не нужны.
Ссылочные типы позволяют избежать лишнего копирования. Но требуют ограничения на операции с ними.
Суть желаемого ограничения на типы-данные сводится к следующему: мутабельный тип — это явная ячейка для хранения иммутабельного значения.
Псевдокод:
data T {...}; // immutable data typemutable<T> var1 = T(); // mutable cell named var1
Проникнись на досуге, что будет в случае составного T. Т.е. с одной стороны, вроде бы и мутабельность есть, с другой стороны, любая мутабельность "транзакционна", т.к. в (предполагаемом) языке нет возможности описать составной мутабельный тип. Зато можно описать мутабельную переменную для хранения значения составного типа "целиком". У тебя не будет возможности подать мутабельную ссылку на часть значения "куда-то" и не знать, что же "где-то там" происходит с частью твоего значения. Ты сможешь подать только иммутабельную ссылку. Прямо отсюда становится возможным применять наработки автоматной теории к императивной программе .
Вот причем тут ссылочные типы в условиях мутабельности. Для иммутабельных значений ссылочный тип или нессылочный — не важно. В итоге это всё ведет к детерминированности и применимости наработок автоматной теории к программе. (На сегодня её применять в полный рост нельзя — из-за врожденной недетерминированности кода, порождаемого современными императивными ЯВУ).
ARK>Вопрос только — что будет, если пересчитать не успели, а пришел новый сигнал? В теории можно обрубить вычисления, если результатом их не предполагается побочного эффекта.
Я же сказал — зависит от модели. В базисе сидит простая реактивная модель распространения сигнала. Но на пути его распространения ты можешь ставить дополнительные блоки/компоненты, которые могут превратить простую реактивную модель в некую более сложную. Например, поставь м/у приемником и получателем очередь (т.н. mail-box или channel), и введи новый дополнительный логический поток, который будет выгребать из всех входных мейлбоксов компонента и делать push в этом логическом потоке — вот тебе уже полноценная асинхронная агентская среда. Оно же COM STA в своё время — неимоверно удобно. А для многих сценариев подходящи более простые политики, чем бесконечная по размеру очередь событий, например — вырожденная очередь с 1-м элементом без потерь (блокирующая очередь), либо неблокирующая вырожденная очередь опять с 1-м элементом, но уже с потерей (перезаписью) старого значения. Пример для последнего — посылка оповещений о прогрессе некоей операции в поток GUI для отображения через progress-bar. Или например, у меня для целей обработки сигналов в каждом "разъеме" сидит защелка, а сами вычисления двухтактные: в первом такте происходит вычисление выходных значений всех компонент в зависимости от входных (формирование выхода), а в следующем такте эти вычисленные выходные значения запоминаются на защелках и попадают на входные пины целевых компонент. Таким образом, зацикливание есть, но оно потактовое, а не бесконечное (как ты опасался). А зацикливание это нужно обязательно — хотя бы на примере обычного затухающего эха. В простейшем варианте эхо реализуется на линии задержки с обратной связью.
В общем, обрати внимание на важный момент во всех этих реактивных/агенстких/тому_подобных_схемах — что в самой топологии связей и в политике доставки событий сидит львиная доля семантики конечной программы. Т.е. изкаробки даётся то, что сегодня составляет приличную часть кода многопоточных программ (где каждый программист решает одни и те же типовые задачи в меру своей испорченности, бесконечно дублируя друг друга и отрасль в целом). И еще заметь, что любые "политики" могут быть реализованы просто как промежуточные блоки/компоненты дизайна на пути распространения сигнала, то бишь, с одной стороны — универсальность, с другой стороны (двигаясь дальше в рассуждениях) наделять семантикой можно сами связи либо аппартаменты, в которых живут объекты. Опять на помню про COM/DCOM и предоставляемый автоматический маршаллинг для типов данных OLE и составных из них. Прикол в том, что описание маршаллинга декларативно, а задается отношениями аппартаметнов, в коорых живут компоненты. В общем, на COM/DCOM/OLE надо смотреть не только на интерфейс IUnknown, ес-но. На сегодня это самая развитая компонентная архитектура. Скажем так, CORBA или джавовские и дотнетные фреймворки по полноте охвата проблемы и близко не валялись. Если не веришь — попробуй на досуге накарябать GUI out of proc server.
ARK>Только будет ли компилятор достаточно умен, чтобы отслеживать такие вещи...
Не будет и не должен — это же часть семантики. По мне, дело "идеального" компилятора — предоставить удобные ср-ва для управления этой семантикой + некий фреймворк с кучей уже реализованных политик + возможность добавлять свои.
V>>Логику можно усложнить. Например, реагировать не на факт подачи сигнала, а лишь на изменение входного значения. ARK>ИМХО, имеет смысл реагировать только на изменение — во всех случаях.
Пример банального звукового кодека показывает — почему нет. Ведь важен каждый входной звуковой отсчет.
К сожалению, всё что я видел из готового на эту тему обычно обыгрывают какую-то одну модель распространения сигналов из перечисленных, так что любую другую модель приходится долго и нудно кодить ручками, как в обычном ООП.
V>>Кстате, для эрудиции, базовый в схемотехнике RS-триггер — это классический асинхронный автомат, то бишь, автомат, выполненый на "чистых" функциях — логических вентилях. ARK>Да, кое-что слышал об этом.
V>>Прямо отсюда должно быть понятно, почему я не сильно отличаю императивный и функциональный подход. Подобные устойчивые системы могут быть гораздо более сложными, чем RS-триггер. Могут состоять из кучи абсолютно чистых ф-ий, но при этом обладать изменяемым состоянием. Достаточно в ФП-программе суметь создать, например, циклическую структуру данных — и ву а ля, вот тебе изменяемое состояние из бесконечно считаемых по кругу ф-ий. Текущее устойчивое значение ф-ии на каждом витке вполне можно принять за состояние (как это есть в RS-триггере). Например, в упрощенном виде такая циклическая структура дана в виде монады IO в Хаскеле (при том, что её зацикливание выполняется внешним, по отношению к программе, вычислителем).
ARK>Тут уже появляется новая сущность — некое "устойчивое состояние" системы. ИМХО, это сильно усложняет понимание программы.
Ну как бы считается, что система должна переходить из одного устойчивого состояния в другое, в этом цель. Собсно, то, что называют "устойчивым к исключению кодом" с разными по силе гарантиями — это лишь разные градации приближения к обсуждаемому.
V>>Если компонент может сигнализировать об ошибке — пусть у него будет под это специальный пин. ARK>А если мы забудем поверить этот специальный пин?
А в 90% слчаев — и ради бога. Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
V>>Если речь о зависимых типах, то мы просто не сможем подать на такой входной пин неподходящий выходной. Система типов не даст. ARK>Вот это интересный момент. Как вы себе это представляете? Это же те самые контракты.
Ну так ограничения, которые можно огранизовать через систему типов зависят исключительно от вида этой системы (от координаты в лямбда-кубе по ссылке). Введи себе параметризуемость термами в систему типов компоент и строй себе зависимые ограничения. Какие проблемы?
V>>Это цикл, а не короткое замыкание. Короткое замыкание — это когда гонки. А цикл — это очень полезная структура. )) ARK>Ну окей, пусть цикл. По-моему, возможность зацикливания надо бы устранить, нет?
Рекурсивные цифровые фильтры, фленжеры, ревербераторы и т.д. — это всё примеры зацикленных алгоритмов.
Я понимаю, о чем ты, просто прямое реактивное распростраение событий — это лишь базис, сверхку которого можно накладывать эффекты на распростраение сигнала. Например, возьми программную модель RS-триггера. В реальности логические ключи как бы "вычисляют" выходную ф-ию от входа непрерывно и постоянно. Но при моделировании в ПО, нет смысла пересчитывать бесконечно по кругу состояния вентилей триггера, если каждый новый пересчет не обновляет их выходы. На то оно и устойчивое состояние, что переходные процессы завершились. Вот он, переход от чистых ф-ий к памяти. Память — это всего лишь св-во устойчивости бесконечных вычислений.
Re[5]: Заметка: Компонентная философия и реализация
Большое спасибо за развернутый ответ.
V>Почти весь этот design by contract можно вложить в систему типов хотя бы С++ еще аж прошлого стандарта безо-всякого abstraction penalty. То бишь, это всё костыли для недостаточно выразительных систем типов в координатах лямбда-куба. В системах можно выразить вообще весь design by contract. С++ относится к системе типов Лw.
Я немного интересовался зависимыми типами, в принципе, они позволяют проверить многое. Но на С++ вряд ли возможно реализовать даже малую часть DBC. Как статически проверить штуки типа "параметр > 3"?
V>В любом случае, я бы не стал ограничения на входные и выходные данные приравнивать к семантике. V>Ну ОК, тогда не стоит пользоваться термином "семантика" для описания того, что же нам гарантируют типизированные интерфейсы. Собсно, об этом я и говорил.
Как я понимаю, семантика в более широком смысле — это нечто типа такой ситуации: в методе 4-этажная формула, определенная комбинация параметров в которой приводит к делению на ноль. В результате предусловием метода является еще более адская формула, обратная первой (получается, что смысла в такой проверке не много). Или речь не о том?
V>Ага, т.е. чем "жирнее" интерфейс, тем меньше вероятность его "случайной" реализации, не?
Разумеется.
V>Я примерно так себе и представляю причину, почему идея разбить кортеж ф-ий контракта на относительно независимые сигналы встречает инстинктивное сопротивление (не ты первый). Ведь кортеж — уже некое ограничение само по себе.
Можно предложить ввести поверх независимых сигналов несколько "сценариев использования" (необязательных). Типа интерфейсов, но с использованием одних и тех же входов-выходов, определяющих последовательность дергания и все такое. Соответственно, если хоть один сценарий такой определен, то мимо него с компонентом работать нельзя.
V>>>Это зависит от модели расрпостранения сигналов. Если синхронная модель — то последовательность вызовов имеет смысл. Если асинхронная, то тоже имеет, но уже по-другому (реакция лишь на изменения значения, а не на факт поступления 2-в-1-м — сигнала+события).
Вы предполагаете использование обеих моделей? Или все равно в конце концов должна быть выбрана какая-то одна? По-моему, код программы должен писаться строго под какую-то одну. Базис, наверное, все же синхронный, стало быть последовательность вызовов контролировать было бы неплохо.
V>Боюсь, лучшим выходом здесь будут не контракты, предписывающие что в каком порядке дергать, а декларативность. Угу, в сочетании с изменяемым состоянием. Необходимо описать реакцию на входное воздействие. Т.к. низлежащий вычислитель будет гарантировать отсутствие гонок, то эта реакция вполне может пользоваться персистентными данными (сохраняемыми от вызова к вызову). Поэтому становится возможным реализовать, например, рекурсивный цифровой фильтр:
Хм, тогда получается, что почти всегда должен быть выход "ошибка", если функция не определена при определенных комбинациях входов — ведь реакция должна быть всегда. ИМХО, явный запрет на встраивание компонента "неправильным образом" повысило бы надежность системы.
V>Не внутри, а снаружи. Синхронизация в пользовательском коде — самый быстрый путь к дедлокам. )) V>Я уже не говорю о провальной получаемой эффективности, если решать вопросы синхронизации "по-месту" и таких мест набирается немеряно.
Тогда тут надо прояснить, в каком виде вы предполагаете иметь изменяемое состояние:
1. Обычные "поля с данными", а-ля ООП. Как тут внешнюю синхронизацию сделать, я не знаю.
2. Хранение состояния через ввод "устойчивого состояния системы". Тут вся синхронизация автоматически обеспечивается внешним вычислителем.
V>Типы — ес-но. Просто хотел бы иметь некую иерархию типов: данные отдельно, "вычислители" — отдельно. И разные правила для разных сортов типов.
Есть еще вот такой момент. Мыслю с точки зрения обычного ООП. Например, мне нужна в моем компоненте работа с файлом. Значит я должен ввести кучу пинов, к которым подключаю компонент, работающий с файлами. Т.к. все пины только примитивных типов, то их будет куча для каждого мало-мальски сложного объекта. Нет ли тут проблемы?
V>Копирование компилятором не убирается, потому что его просто нет. )))
Ну, если в модели нет, то ради бога.
V>Такое протаскивание выполняется только в момент построения топологии схемы, а затем сигналы идут непосредственно от источника к приемнику.
Да, это я понял.
V>Суть желаемого ограничения на типы-данные сводится к следующему: мутабельный тип — это явная ячейка для хранения иммутабельного значения. V>Проникнись на досуге, что будет в случае составного T. Т.е. с одной стороны, вроде бы и мутабельность есть, с другой стороны, любая мутабельность "транзакционна", т.к. в (предполагаемом) языке нет возможности описать составной мутабельный тип. Зато можно описать мутабельную переменную для хранения значения составного типа "целиком". У тебя не будет возможности подать мутабельную ссылку на часть значения "куда-то" и не знать, что же "где-то там" происходит с частью твоего значения. Ты сможешь подать только иммутабельную ссылку. Прямо отсюда становится возможным применять наработки автоматной теории к императивной программе .
Понятно. Хотя я не вижу, где в вашей модели нужна мутабельность, кроме как в переменных внутри метода для простоты программирования.
V>Я же сказал — зависит от модели. В базисе сидит простая реактивная модель распространения сигнала. Но на пути его распространения ты можешь ставить дополнительные блоки/компоненты, которые могут превратить простую реактивную модель в некую более сложную. Например, поставь м/у приемником и получателем очередь (т.н. mail-box или channel), и введи новый дополнительный логический поток, который будет выгребать из всех входных мейлбоксов компонента и делать push в этом логическом потоке — вот тебе уже полноценная асинхронная агентская среда. Оно же COM STA в своё время — неимоверно удобно. А для многих сценариев подходящи более простые политики, чем бесконечная по размеру очередь событий, например — вырожденная очередь с 1-м элементом без потерь (блокирующая очередь), либо неблокирующая вырожденная очередь опять с 1-м элементом, но уже с потерей (перезаписью) старого значения. Пример для последнего — посылка оповещений о прогрессе некоей операции в поток GUI для отображения через progress-bar. Или например, у меня для целей обработки сигналов в каждом "разъеме" сидит защелка, а сами вычисления двухтактные: в первом такте происходит вычисление выходных значений всех компонент в зависимости от входных (формирование выхода), а в следующем такте эти вычисленные выходные значения запоминаются на защелках и попадают на входные пины целевых компонент. Таким образом, зацикливание есть, но оно потактовое, а не бесконечное (как ты опасался). А зацикливание это нужно обязательно — хотя бы на примере обычного затухающего эха. В простейшем варианте эхо реализуется на линии задержки с обратной связью.
Если я правильно понял, то в модели автоматическое отсечение ненужных вычислений не предполагается. В принципе, это разумно, потому что это всего лишь оптимизация.
ARK>>Только будет ли компилятор достаточно умен, чтобы отслеживать такие вещи... V>Не будет и не должен — это же часть семантики. По мне, дело "идеального" компилятора — предоставить удобные ср-ва для управления этой семантикой + некий фреймворк с кучей уже реализованных политик + возможность добавлять свои.
Да нет, не часть семантики, в том-то и дело. Я говорю о 100% бесполезных вычислениях (потерявших актуальность в результате прихода нового сигнала). А бесполезные они или нет — определяется как раз топологией соединения. Или я чего-то не понимаю.
V>Пример банального звукового кодека показывает — почему нет. Ведь важен каждый входной звуковой отсчет.
Да, совершенно верно.
V>>>Если компонент может сигнализировать об ошибке — пусть у него будет под это специальный пин. ARK>>А если мы забудем поверить этот специальный пин? V>А в 90% слчаев — и ради бога. Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
Вот не нравится мне этот момент. Я, как программист, могу просто забыть этот пин проверить. Это как возврат кода ошибки в С. А результат функция все равно вернет, причем валидный — просто какое-то дефолтное значение. Аналог — в дотнете вызываем Int32.TryParse(str, out val) и берем val, не проверив результат функции. В val всегда что-то будет, но блин — это же неправильно.
А вот если бы TryParse возвращал (None | Some Int32), то все — не отвертишься, ошибку надо проверить.
Или содержал предусловие IsValidString(), которое обязывало бы программиста вызвать этот самый IsValidString перед вызовом Parse.
V>Ну так ограничения, которые можно огранизовать через систему типов зависят исключительно от вида этой системы (от координаты в лямбда-кубе по ссылке). Введи себе параметризуемость термами в систему типов компоент и строй себе зависимые ограничения. Какие проблемы?
Понял. Т.е. этот момент вы рассматриваете отдельно от модели. Поэтому мои рассуждения выше, похоже, не в тему.
V>Я понимаю, о чем ты, просто прямое реактивное распростраение событий — это лишь базис, сверхку которого можно накладывать эффекты на распростраение сигнала. Например, возьми программную модель RS-триггера. В реальности логические ключи как бы "вычисляют" выходную ф-ию от входа непрерывно и постоянно. Но при моделировании в ПО, нет смысла пересчитывать бесконечно по кругу состояния вентилей триггера, если каждый новый пересчет не обновляет их выходы. На то оно и устойчивое состояние, что переходные процессы завершились. Вот он, переход от чистых ф-ий к памяти. Память — это всего лишь св-во устойчивости бесконечных вычислений.
Понятно.
Еще пришло в голову вот что: можно ли подключить к одному выходу произвольное количество входов? Типа multicast delegate в дотнете.
Если нет, то такое ограничение вроде как бесполезно: мы ведь всегда можем сделать разветвитель, тупо пробрасывающий один вход на произвольное количество выходов?
Re[21]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>У меня есть и поля(забегая немного вперёд — у меня, интерфейсы(публичные контракты) состоят только из полей, а методы это поля функционального типа(которым могут присваиваться функции)). AVK>>У меня тот же. Я вот только не пойму что ты подразумеваешь под потоками данных. К примеру, поток координат и нажатий кнопок от мыша — это поток данных или нет? AC>Да, это поток данных(а точнее сообщений), извлекаемых main thread'ом из очереди, в цикле без callback'ов.
Извлекает у тебя диспетчер (алгоритм из ровно 2-х строчек), который затем раздает сообщения целевым оконным ф-иям. Каждая такая оконная ф-ия — классический callback.
Re[22]: Заметка: Компонентная философия и реализация
AVK>>>У меня тот же. Я вот только не пойму что ты подразумеваешь под потоками данных. К примеру, поток координат и нажатий кнопок от мыша — это поток данных или нет? AC>>Да, это поток данных(а точнее сообщений), извлекаемых main thread'ом из очереди, в цикле без callback'ов. V>Извлекает у тебя диспетчер (алгоритм из ровно 2-х строчек), который затем раздает сообщения целевым оконным ф-иям. Каждая такая оконная ф-ия — классический callback.
Вообще из 4-х строк(две другие — while и TranslateMessage()), но не суть, это я к тому, что callback'и не единственной способ реализовать реакцию на сообщение.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[23]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
V>>Извлекает у тебя диспетчер (алгоритм из ровно 2-х строчек), который затем раздает сообщения целевым оконным ф-иям. Каждая такая оконная ф-ия — классический callback. AC>Вообще из 4-х строк(две другие — while и TranslateMessage()), но не суть, это я к тому, что callback'и не единственной способ реализовать реакцию на сообщение.
Ес-но не единственный... Есть еще poll-схема вычислений (как раз эти 4 строчки), и большинство кода на сегодня написано именно в poll-стиле. Но попробуй написать всё GUI-приложение в этом poll-цикле диспетчеризации сообщений и ты увидишь, что местами push-схема удобней многократно. Хоть она и сложнее (требует инфраструктуру/поддержку).
Считай, что твои 4 строчи кода и DispatchMessage — это и есть инфраструктура для подержки реактивного подхода к построению программы.
Re[20]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали:
ARK>>>А если мы забудем поверить этот специальный пин? V>>А в 90% слчаев — и ради бога. Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
ARK>Вот не нравится мне этот момент. Я, как программист, могу просто забыть этот пин проверить.
Не забудешь, ты же его не опрашиваешь, он пришлет тебе в стиле push оповещение. А если тебе нужны ограничения — то можно задать ограничение на запрет "висячего" состояния этого пина в компоненте-источнике. )) И тогда, чтобы намеренно проигнорировать этот пин, тебе придется явно подключить к нему каку-нить заглушку.
Сорри, я просто не знаю с какой степенью подробностей это всё объяснять — мне многое кажетсяи так понятным. Представь, что ты электронщик и собираешь из "рассыпухи" (кучи компонент) целевую схему. Некоторые компоненты могут давать сигнал ошибки, некоторые — нет. Например, сумматор может давать признак переноса, и ты можешь считать его согласно своей логики за ошибку (потерю значения) или нет, если это счетчик фазы, например, тогда переполнение до фени.. Просто ты согласно спецификации "протягиваешь" на выход сигнал, который для тебя является ошибкой. Как внести порядок в случай, когда у нас много таких источников? Например, ставишь некоторую логическую схему (приоритетную, скажем), на входах которой упорядочиваешь сигналы ошибок от "рассыпухи", а выход этой приоритетной схемы подаешь как выход ошибки компонента либо напрямую, либо обогащая некотороей "высокоуровневой" информацией уровня уже целого компонента.
Фильтрация исключений на стороне их перехвата в современном ПО делает тоже самое: выполняет некую логику по обслуживанию ошибок низлежащих компонент и формирует из них более высокоуровневые ошибки.
ARK>Это как возврат кода ошибки в С.
Дык, синхронные исключения (как в Java/C#) — это тоже как возврат кода ошибки, если смотреть на происходящее. Просто за синтаксисом ловли исключений catch и за иерархией самих объектов-исключений прячется точно такая же механика приоритизированных хуков — КОЛБЕКОВ! ))) Разве что спрятанная от тебя механика по выбору нужного хука проверяет не пользовательский числовой код, как в C, а некий внутренний числовой код — метку/хендл рантайм-типа проброшенного объекта-исключения...
А теперь информация к медитации: когда числодробилка на C++ построена на пустых throw() (объявляет, что ф-ия не выкидывает исключения), то она работает до 15%-25% быстрее, чем с включенными исключениями. А если отключить асинхронные исключения (SEH), то еще на 5% быстрее... Т.е. не бесплатно это всё.. надо же еще стек при этом раскручивать, так? Ведь выход из хука может вести на другой фрейм стека в иерархии вызовов. В С++ это делается неявным кодом, раскручивающим стек, в дотнете для аналогичного надо сказать компилятору using (транслируемый в finally), иначе содержимое фрейма молча отбрасывается. Поэтому в C#/Java исключения обычно дешевле плюсовых, если не посыпать код обильно try/catch... но зато запросто можно забыть о ресурсах (о using).
ARK>А результат функция все равно вернет, причем валидный — просто какое-то дефолтное значение.
Что захочешь, то и вернет. Не нужен отдельный "асинхронный" пин, рапортующий об ошибке? — сделай тип сигнала maybe<int>.
ARK>А вот если бы TryParse возвращал (None | Some Int32), то все — не отвертишься, ошибку надо проверить. ARK>Или содержал предусловие IsValidString(), которое обязывало бы программиста вызвать этот самый IsValidString перед вызовом Parse.
В случае maybe случае ты протягиваешь ошибку по "основному" каналу. Но дело дизайна, то бишь вкуса. Если нужна именно такая логика — ради бога. В другом месте может оказаться нужнее быстрее протянуть ошибку на нужный сколь угодно выскоий уровень по совсем другому пути, чем по логике основного сигнала. Т.е. я предлагаю по-сути механизм, аналогичный исключениям, только на порядки более гибкий... И да, ошибиться всегда тем легче, чем гибче.
V>>Ну так ограничения, которые можно огранизовать через систему типов зависят исключительно от вида этой системы (от координаты в лямбда-кубе по ссылке). Введи себе параметризуемость термами в систему типов компоент и строй себе зависимые ограничения. Какие проблемы?
ARK>Понял. Т.е. этот момент вы рассматриваете отдельно от модели. Поэтому мои рассуждения выше, похоже, не в тему.
С одной стороны — да, не в тему, бо для реализации реактивной среды нужен самый минимум в системе типов (достаточно умения косвенного вызова ф-ий, то бишь пойдёт любой язык с с возможностью косвенных вызовов процедур (ЯП с указателями на ф-ии, либо ООП, либо ФП).
С другой стороны, ограничения, выраженные через систему типов — это интересная тема сама по себе, в обсуждении которой я тоже обычно с удовольствием участвую. Просто эта тема ортогональна реактивности, бо эти же ограничения действуют и в "привычно-построенной" программе.
V>>Я понимаю, о чем ты, просто прямое реактивное распростраение событий — это лишь базис, сверхку которого можно накладывать эффекты на распростраение сигнала. Например, возьми программную модель RS-триггера. В реальности логические ключи как бы "вычисляют" выходную ф-ию от входа непрерывно и постоянно. Но при моделировании в ПО, нет смысла пересчитывать бесконечно по кругу состояния вентилей триггера, если каждый новый пересчет не обновляет их выходы. На то оно и устойчивое состояние, что переходные процессы завершились. Вот он, переход от чистых ф-ий к памяти. Память — это всего лишь св-во устойчивости бесконечных вычислений.
ARK>Понятно.
ARK>Еще пришло в голову вот что: можно ли подключить к одному выходу произвольное количество входов? Типа multicast delegate в дотнете.
Можно, такой multicast-callback называется паттерном Observer, и есть целый дотнетный фреймворк вокруг него для типа IObservable<>.
Это обратное подключение — зло. Ну реально, все "ужасы императива", которыми пугают нас функциональщики, связаны с тем, что одно и то же состояние может быть скрыто изменено. Почему так происходит? Потому что ссылка на состояние размножена по программе, .е. есть возможность асихронной подачи воздействий из разных мест. ИМХО, такая возможность не должна быть by default, как оно есть сейчас в многопоточном императивном ПО. Именно "агентские" среды и прочие конструкторы пытаются решить все эти проблемы случайных гонок, дав надежную асинхронную среду. Тут на сайте лежит перевод статьи по Сингулярити, есть о чем почитать на эту тему.
ARK>Если нет, то такое ограничение вроде как бесполезно: мы ведь всегда можем сделать разветвитель, тупо пробрасывающий один вход на произвольное количество выходов?
Именно так. Поэтому я в своих поделках всегда даю singlecast-callback, а "разветвитель" идет отдельным компонентом, дополняющим обычный callback до observer. Впрочем, я уже об этом писал: http://www.rsdn.ru/forum/philosophy/4957810.1
Здравствуйте, vdimas, Вы писали:
V>Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
Да, это все верно. Главное, чтобы работа с этими детерминированными линиями ошибки не слишком засоряла основной функционал (этого как раз пытаются обычно достичь с помощью исключений).
V>Не забудешь, ты же его не опрашиваешь, он пришлет тебе в стиле push оповещение.
Ну на самом-то деле все равно где-то будет программный код — в описании функционала выходов. И в этом коде программист как раз должен "дергать" выходы другого компонента, возможно, при особых условиях.
Например. Есть компонент с двумя входами — A и B, одним выходом — C. Значение C = A / B.
Да, я могу запрограммировать C как "return (B != 0) ? (A / B) : 0", но я этого не хочу. Я хочу, чтобы C имел смысл только в случае, когда B != 0.
Таким образом, мы не можем подключить наш компонент как попало. Например, мы не имеем права поставить на вход B заглушку, подающую константу "0" (это не имеющий смысла пример, вырожденный случай) — программа не должна скомпилироваться.
V>А если тебе нужны ограничения — то можно задать ограничение на запрет "висячего" состояния этого пина в компоненте-источнике. )) И тогда, чтобы намеренно проигнорировать этот пин, тебе придется явно подключить к нему каку-нить заглушку.
Но ограничения могут быть более комплексными, чем просто запрет висячего провода.
V>Некоторые компоненты могут давать сигнал ошибки, некоторые — нет. Например, сумматор может давать признак переноса, и ты можешь считать его согласно своей логики за ошибку (потерю значения) или нет, если это счетчик фазы, например, тогда переполнение до фени.
А вдруг компонент не просто выдает опциональный сигнал ошибки, а требует, чтобы этот сигнал нельзя было проигнорировать?
ARK>>Это как возврат кода ошибки в С.
V>Дык, синхронные исключения (как в Java/C#) — это тоже как возврат кода ошибки, если смотреть на происходящее. Просто за синтаксисом ловли исключений catch и за иерархией самих объектов-исключений прячется точно такая же механика приоритизированных хуков — КОЛБЕКОВ! ))) Разве что спрятанная от тебя механика по выбору нужного хука проверяет не пользовательский числовой код, как в C, а некий внутренний числовой код — метку/хендл рантайм-типа проброшенного объекта-исключения...
Ну, что в самом низу, для верхнего программиста не так важно. Разница в том, что исключение все эти штуки делает за сценой, плюс его нельзя проигнорировать, в отличие от кодов ошибок.
V>Что захочешь, то и вернет. Не нужен отдельный "асинхронный" пин, рапортующий об ошибке? — сделай тип сигнала maybe<int>.
Maybe — это достаточно простая вещь, хотя и очень полезная. Кстати, а какие еще примитивные типы вы предполагаете использовать?
Но ограничения могут быть в теории гораздо более комплексные, чем maybe... Например, затрагивающие сразу несколько пинов.
V>С другой стороны, ограничения, выраженные через систему типов — это интересная тема сама по себе, в обсуждении которой я тоже обычно с удовольствием участвую. Просто эта тема ортогональна реактивности, бо эти же ограничения действуют и в "привычно-построенной" программе.
Да, это верно и для обычного программирования. Просто как-то мне кажется, что на реактивно-компонентную модель они могут лечь более естественно. Превращаются в этакие правила совместимости компонентов. Как разъем HDMI нельзя воткнуть в DVI.
Да, и все-таки интересно было бы услышать ваше мнение по поводу двух вопросов из прошлого моего поста:
Изменяемое состояние у вас предполагается в виде "устойчивых состояний системы"? (Выше по треду об этом был разговор на примере RS-триггера.) Или будет какой-то аналог полей-атрибутов из ООП (во что слабо верится)?
и
"Есть еще вот такой момент. Мыслю с точки зрения обычного ООП. Например, мне нужна в моем компоненте работа с файлом. Значит я должен ввести кучу пинов, к которым подключаю компонент, работающий с файлами. Т.к. все пины только примитивных типов, то их будет куча для каждого мало-мальски сложного объекта. Нет ли тут проблемы?"
Т.е. вопрос в том, не возникнет ли чрезмерного количества пинов у сложных компонентов из-за отсутствия абстрагирующих сложность сущностей типа ООП-шных объектов?
Здравствуйте, AlexCab, Вы писали:
AC>В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Ну это не совсем будущее, скорее начало 90х, OLE, вот это все
Будущее, как мне кажется, за технологиями, которые позволят легко программировать то, что сейчас программировать очень сложно, либо вообще невозможно, либо позволят вообще не программировать.
Например, такие вещи как MATLAB, R или Mathematica для целого круга задач подходят куда лучше чем обычные языки программирования. Иногда бывает так, что вместо разработки своего велосипеда, решающего некую проблему, намного проще, быстрее и эффективнее написать страницу кода на R и заинтерфейсить его из своего приложения.
В общем, я за специализированые инструменты и против серебрянных пуль в любом виде
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, Lazin, Вы писали: L>Будущее, как мне кажется, за технологиями, которые позволят легко программировать то, что сейчас программировать очень сложно, либо вообще невозможно, либо позволят вообще не программировать.
Как раз над этим и работаю L>Например, такие вещи как MATLAB, R или Mathematica для целого круга задач подходят куда лучше чем обычные языки программирования. Иногда бывает так, что вместо разработки своего велосипеда, решающего некую проблему, намного проще, быстрее и эффективнее написать страницу кода на R и заинтерфейсить его из своего приложения.
MATLAB замечательный пример комбайна, создание и интегрирование которых, с помощью КОП, станет проще. L>В общем, я за специализированые инструменты и против серебрянных пуль в любом виде
Не согласен. Если цена использования универсального инструмента на множестве решаемых задач(M) равна или меньше цени использования множества специальных инструментов на M, лучше выбрать универсальный.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>MATLAB замечательный пример комбайна, создание и интегрирование которых, с помощью КОП, станет проще.
У матлаба уже есть своя компонентная модель, которая на мой взгляд намного лучше предложенной в статье. Компоненты, описаные в сатье похожи на обычные объекты, у которых есть интерфейсы, методы и тд. Т.е. сложный, структурированный интерфейс. Я могу их комбинировать самым обычнм образом. Это очень низкоуровневый инструмент, возможно он поможет писать код, но код мы и так писать умеем.
В матлабе же есть множество тулбоксов, каждый тулбокс содержит набор функций, имеет документацию и тд, но это не объект. Все функции, которые содержит тублокс работают с общими типами и доступны из их скриптового языка, с помощью которого выполняется комбинирование компонентов. Скажем, я могу взять OPC toolbox, получить данные в виде обычного вектора и далее, передать эти данные в simulink модель, построенную с помощью другого тулбокса(simulink). Нет никаких интерфейсов и хитрого способа получить OPCDataStream, реализующий IDataStream, который можно передать в метод SimulinkModel.SetInput(IDataStream) xD Но тем не менее все очень хорошо работает и комбинируется между собой. На самом деле, такой уровень удобства комбинирования различных компонентов как в MATLAB мало где можно встретить.
А компонентная модель из статьи породит огромное количество сущьностей и будет сложна в поддержке. Я так и не понял, в чем е поинт, она позволяет стандартизировать ABI, как COM, или упрощает программирование? Для чего она? (я правда все не осилил, может как-нибудь потом)
AC>Не согласен. Если цена использования универсального инструмента на множестве решаемых задач(M) равна или меньше цени использования множества специальных инструментов на M, лучше выбрать универсальный.
Ну, современные тенденции показывают, что специализированные инструменты обычно лучше решают задачу, нежели универсальлные. Скажем, erlang для разработки распределенных систем, ANTLR для создания парсеров и тд.
Re[4]: Заметка: Компонентная философия и реализация
AC>>MATLAB замечательный пример комбайна, создание и интегрирование которых, с помощью КОП, станет проще. L>У матлаба уже есть своя компонентная модель, которая на мой взгляд намного лучше предложенной в статье. Компоненты, описаные в сатье похожи на обычные объекты, у которых есть интерфейсы, методы и тд. Т.е. сложный, структурированный интерфейс.
Вам, как пользователю ПО, будет совершенно не обязательно знать об этом. Это нужно только разработчикам компонентов. L>Я могу их комбинировать самым обычнм образом.
Имея готовый набор компонентов(такой, как например MATLAB), вы сможете комбинировать их каким угодно образом или даже "позволить" им комбинироваться самостоятельно(разумеется если это предусмотрено разробами). L>Это очень низкоуровневый инструмент, возможно он поможет писать код, но код мы и так писать умеем.
Важно понимать что это(как и другие ЯП) всё таки инструмент для создания инструментов, а не для решения непосредственно прикладных задач, т.е. он не может быть "высокоуровневым". L>В матлабе же есть множество тулбоксов, каждый тулбокс содержит набор функций, имеет документацию и тд, но это не объект.
Да, это компоненты(хоть и примитивные). L>Все функции, которые содержит тублокс работают с общими типами и доступны из их скриптового языка, с помощью которого выполняется комбинирование компонентов. Скажем, я могу взять OPC toolbox, получить данные в виде обычного вектора и далее, передать эти данные в simulink модель, построенную с помощью другого тулбокса(simulink). Нет никаких интерфейсов и хитрого способа получить OPCDataStream, реализующий IDataStream, который можно передать в метод SimulinkModel.SetInput(IDataStream) xD Но тем не менее все очень хорошо работает и комбинируется между собой.
Видите как сложно, а моглибы просто написать "connect IData of OPCtoolbox to simulink", или соединить пару прямоугольников на диаграмме. L>На самом деле, такой уровень удобства комбинирования различных компонентов как в MATLAB мало где можно встретить.
Это пока, но скоро... L>А компонентная модель из статьи породит огромное количество сущьностей и будет сложна в поддержке.
Почему вы так считаете? L>Я так и не понял, в чем е поинт, она позволяет стандартизировать ABI, как COM, или упрощает программирование?
Both. L>Для чего она? (я правда все не осилил, может как-нибудь потом)
Для облегчения разработки компонентного ПО.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Вам, как пользователю ПО, будет совершенно не обязательно знать об этом. Это нужно только разработчикам компонентов.
Я сужу с позиции разработчика а не пользователя.
L>>Это очень низкоуровневый инструмент, возможно он поможет писать код, но код мы и так писать умеем. AC>Важно понимать что это(как и другие ЯП) всё таки инструмент для создания инструментов, а не для решения непосредственно прикладных задач, т.е. он не может быть "высокоуровневым".
Ну так мы же говорим о "компонентах" приложения, компоненты должны быть высокоуровневыми сущностями в моем представлении. Компоненты — coarse grained штука, объекты ООП — fine grained. Тащить компонетны на уровень ниже на мой взгляд не имеет особого смысла, так как на этом уровне их потребуется слишком много. Допустим, на создание компонента нужно потратить столько же времени, сколько и на создание обычного класса + время на создание некоторой обвязки для поддержки компонентности + время на повторное использование(компонент нужно как минимум описать). Если абсолютно все представлять в виде компонентов, то можно получить весьма существенный оверхед на время разработки.
AC>Видите как сложно, а моглибы просто написать "connect IData of OPCtoolbox to simulink", или соединить пару прямоугольников на диаграмме.
Для этого где-то должны быть описаны IData и connect. В случае же матлаба, все всегда представлено в виде матриц и для связи компонентов нужно просто тупо передать матрицу из одного компонента в другой.
AC>Почему вы так считаете?
Я уже выше написал, она вводит доп. оверхед на разработку, если компоненты будут слишком низкоуровневыми, то они внесут значительный оверхед на разработку. Ну это как если бы мы вдруг решили использовать вместо обычных классов — COM компоненты. Можно сразу пойти и застрелиться. В статье копоненты живут на достаточно низком уровне, IMO, чтобы пойти и застрелиться
Re[6]: Заметка: Компонентная философия и реализация
AC>>Важно понимать что это(как и другие ЯП) всё таки инструмент для создания инструментов, а не для решения непосредственно прикладных задач, т.е. он не может быть "высокоуровневым". L>Ну так мы же говорим о "компонентах" приложения, компоненты должны быть высокоуровневыми сущностями в моем представлении. Компоненты — coarse grained штука, объекты ООП — fine grained.
В предлагаемой модели высокоуровневыми(coarse grained) являются сборки(компоненты из компонентов). Внутри компонентов(fine grained) — примитивные значения(как например int в Java). Т.е. всё что внутри(по отношению к компоненту) — примитивные значения, всё что снаружи — компоненты. Сами компоненты занимают как-бы промежуточный уровень, ввдение которого позволит реализовать "2)"(см.ниже).
L>Тащить компонетны на уровень ниже на мой взгляд не имеет особого смысла, так как на этом уровне их потребуется слишком много. Допустим, на создание компонента нужно потратить столько же времени, сколько и на создание обычного класса + время на создание некоторой обвязки для поддержки компонентности + время на повторное использование(компонент нужно как минимум описать). Если абсолютно все представлять в виде компонентов, то можно получить весьма существенный оверхед на время разработки.
1)Всё что целесообразно представить в виде примитивных значений(символы, числа, функции etc.) и их коллекций(строки, массивы данных/функций etc.), стоит представить именно так.
2)Компоненты и/или всё приложение может быть полностью или частично собрано из готовых компонентов(так же, как сейчас их собирают из готовых объектов, но проще).
AC>>Видите как сложно, а моглибы просто написать "connect IData of OPCtoolbox to simulink", или соединить пару прямоугольников на диаграмме. L>Для этого где-то должны быть описаны IData и connect. В случае же матлаба, все всегда представлено в виде матриц и для связи компонентов нужно просто тупо передать матрицу из одного компонента в другой.
Если бы... то: Матрица это тип примитивных данных (или прототип компонента) определённый разработчиками Matlab'а, в том числе для обмена между плагинами. IData это интерфейс определённый разработчиком simulink'а. Разработчик OPCtoolbox нашёл IData в документации и подумал: "было-бы хорошо чтобы мой компонент мог передавать матрицу прямиком в simulink-модель" и, реализовал комплимент к IData. А connect это оператор ЯП, он используется для подключения любых интерфейсов.
L>Я уже выше написал, она вводит доп. оверхед на разработку, если компоненты будут слишком низкоуровневыми, то они внесут значительный оверхед на разработку. Ну это как если бы мы вдруг решили использовать вместо обычных классов — COM компоненты. Можно сразу пойти и застрелиться.
Компоненты из заметки это _не_ COM-компоненты, они сами по себе проще, не говоря уж о использовании готовых.
L>В статье копоненты живут на достаточно низком уровне, IMO, чтобы пойти и застрелиться
Думаю, просто вы мыслете на "низком уровне", как если бы в восьмидесятые вы говорили: "Вздор! Как могут, динамические структуры с данными и указателями на функции, сделать программирование проще!?"
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[7]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
L>>Ну так мы же говорим о "компонентах" приложения, компоненты должны быть высокоуровневыми сущностями в моем представлении. Компоненты — coarse grained штука, объекты ООП — fine grained. AC>В предлагаемой модели высокоуровневыми(coarse grained) являются сборки(компоненты из компонентов). Внутри компонентов(fine grained) — примитивные значения(как например int в Java). Т.е. всё что внутри(по отношению к компоненту) — примитивные значения, всё что снаружи — компоненты. Сами компоненты занимают как-бы промежуточный уровень, ввдение которого позволит реализовать "2)"(см.ниже).
По моему таки низкоуровневый. Вот в примере http сервера, все компоненты — достаточно низкоуровневые сущности, например connection. Connection это никак не компонент, это обычный объект. Компонент это весь http сервер например.
AC>1)Всё что целесообразно представить в виде примитивных значений(символы, числа, функции etc.) и их коллекций(строки, массивы данных/функций etc.), стоит представить именно так. AC>2)Компоненты и/или всё приложение может быть полностью или частично собрано из готовых компонентов(так же, как сейчас их собирают из готовых объектов, но проще).
Сложнее. Например связи между компонентами. Вы предлагаете управлять памятью вручную, мало того, явно специфицировать тип соединения — статическое оно или динамическое. Мало того, что такой подход усложняет программирование. Он еще и усложняет или даже делает невозможным autowiring a-la spring и тд. Механизма интроспекции мною замечено небыло. Механизма управления ресурсами тоже (только временем жизни объектов).
AC>>>Видите как сложно, а моглибы просто написать "connect IData of OPCtoolbox to simulink", или соединить пару прямоугольников на диаграмме. L>>Для этого где-то должны быть описаны IData и connect. В случае же матлаба, все всегда представлено в виде матриц и для связи компонентов нужно просто тупо передать матрицу из одного компонента в другой. AC>Если бы... то: Матрица это тип примитивных данных (или прототип компонента) определённый разработчиками Matlab'а, в том числе для обмена между плагинами. IData это интерфейс определённый разработчиком simulink'а. Разработчик OPCtoolbox нашёл IData в документации и подумал: "было-бы хорошо чтобы мой компонент мог передавать матрицу прямиком в simulink-модель" и, реализовал комплимент к IData. А connect это оператор ЯП, он используется для подключения любых интерфейсов.
Я тут не очень понял. Какой еще IData в симулинке?
Вообще, я тут давно пытаюсь на одну простую мысль навести, но без толку. Прмер 1: есть много компонентов, у них есть множество интерфейсов, glue code должен соединять входы и выходы, возможно описывать какие либо адаптеры для преобразования интерфейсов. Это как если бы у нас была куча оборудования, у каждого устройства был бы свой тип разъема и мы все соединяли бы кабелями, иногда используя переходники. Пример 2: подход матлаба и некоторых других продуктов. У нас есть общая шина — в случае матлаба это workspace. По этой шине не передаются всякие сложные типы, вроде структур, только ограниченый набор примитивных типов, например числа, строки, массивы и словари. Ну а передача данных от компонента к компоненту может выполняться уже с помощью m-script. Это как если бы все наше оборудование подключалось бы к одной общей шине, а не друг к другу.
L>>В статье копоненты живут на достаточно низком уровне, IMO, чтобы пойти и застрелиться AC>Думаю, просто вы мыслете на "низком уровне", как если бы в восьмидесятые вы говорили: "Вздор! Как могут, динамические структуры с данными и указателями на функции, сделать программирование проще!?"
Наоборот, пока что вы придумали недо-COM. Идеи, реализованные в COM — куда более прогрессивны, там например нет привязки к языку, стандартизирван ABI, есть поддержка сложной динам. диспетчеризации, есть поддержка многопоточности(аппартаменты/маршалинг и все такое). COM — по настоящему модульная штука, а то что описано в статье — не очень.
Re[8]: Заметка: Компонентная философия и реализация
L>По моему таки низкоуровневый. Вот в примере http сервера, все компоненты — достаточно низкоуровневые сущности, например connection. Connection это никак не компонент, это обычный объект.
Какой же он объект У него нет ни полей ни методов, его нужно только создать и передать нач. параметры, а дальше он будет работать сам(т.е. им не нужно управлять).
(но вообще-то я стараюсь сделать компоненты более похожими на объекты, чтобы переход к компонентному программированию был более простым) L>Компонент это весь http сервер например.
Достаточно просто, упаковать все составляющие компоненты в сборку, и можно работать с сервером как с монолитной, единственной сущностью. AC>>2)Компоненты и/или всё приложение может быть полностью или частично собрано из готовых компонентов(так же, как сейчас их собирают из готовых объектов, но проще). L>Сложнее. Например связи между компонентами. Вы предлагаете управлять памятью вручную,
Ни в коем случае, нужно управлять только связями компонентов, а в идеале даже этого не требуется т.к. хорошим стилем считается разработка компонентов, которые самостоятельно управляют своими связями. L>мало того, явно специфицировать тип соединения — статическое оно или динамическое.
Нет, соединения компонентов всегда динамические(или вы мели ввиду что-то другое?). L>Мало того, что такой подход усложняет программирование. Он еще и усложняет или даже делает невозможным autowiring a-la spring и тд.
Насколько я понял, autowiring это возможность позволяющая автоматически заполнять поля объекта ссылками на другие объекты, для того чтобы сделать их доступными в контексте объекта. В КОП используется другой механизм, чтобы сделать один компонент доступным другому, необходимо соединить(подключить) их интерфейсы. L>Механизма интроспекции мною замечено небыло.
Непосредственно ЯП не поддерживается, но может быть реализована, например в виде интерфейса IComponentInfo. L>Механизма управления ресурсами тоже (только временем жизни объектов).
Управление ресурсами (кроме памяти) по идее должно выполняется компонентами, ответственными за эти ресурсы. Освобождение ресурсов в таких компонентах может выполнятся в деконструкторе, автоматически вызываемом при разрушении компонента. L>Я тут не очень понял. Какой еще IData в симулинке?
Это я описал как было бы, если б Matlab был построен по принципам КОП-модели из заметки. L>Вообще, я тут давно пытаюсь на одну простую мысль навести, но без толку. Прмер 1: есть много компонентов, у них есть множество интерфейсов, glue code должен соединять входы и выходы, возможно описывать какие либо адаптеры для преобразования интерфейсов. Это как если бы у нас была куча оборудования, у каждого устройства был бы свой тип разъема и мы все соединяли бы кабелями, иногда используя переходники.
Именно такой подход используется в переложенной модели, плюс компоненты могут соединятся самостоятельно(в этом случае glue code не нуже). L>Пример 2: подход матлаба и некоторых других продуктов. У нас есть общая шина — в случае матлаба это workspace. По этой шине не передаются всякие сложные типы, вроде структур, только ограниченый набор примитивных типов, например числа, строки, массивы и словари. Ну а передача данных от компонента к компоненту может выполняться уже с помощью m-script. Это как если бы все наше оборудование подключалось бы к одной общей шине, а не друг к другу.
Без проблем реализуется: один из компонентов — общая шина. L>Наоборот, пока что вы придумали недо-COM. Идеи, реализованные в COM — куда более прогрессивны, там например нет привязки к языку,
IDL? L>стандартизирван ABI,
Собственно для этого COM и созавался L>есть поддержка сложной динам. диспетчеризации,
Что имеется ввиду? L>есть поддержка многопоточности(аппартаменты/маршалинг и все такое).
Хочу сделать многокрасочность как в Go: каждый вызов функции в новом потоке. L>COM — по настоящему модульная штука, а то что описано в статье — не очень.
Да, COM хорошая штука, но он бинарный и он сложен в использовании.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[9]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
L>>Connection это никак не компонент, это обычный объект. AC>Какой же он объект У него нет ни полей ни методов, его нужно только создать и передать нач. параметры, а дальше он будет работать сам(т.е. им не нужно управлять).
Connection, в голове любого программиста, это соединение по какому-нибудь протоколу, которое умеет send/recv/close/shutdown. Код, который знает детали протокола обмена обычно вызывает эти методы, обмениваясь данными с удаленным хостом. Не понимаю как это "не нужно управлять".
L>>Компонент это весь http сервер например. AC>Достаточно просто, упаковать все составляющие компоненты в сборку, и можно работать с сервером как с монолитной, единственной сущностью.
А зачем тогда все делается на компонентах?
L>>мало того, явно специфицировать тип соединения — статическое оно или динамическое. AC>Нет, соединения компонентов всегда динамические(или вы мели ввиду что-то другое?).
Ну в статье идет речь о статических и динамических связях между компонентами, в разделе "управление памятью". Мне кажется делить связи по типам — излишнее усложнение.
L>>Мало того, что такой подход усложняет программирование. Он еще и усложняет или даже делает невозможным autowiring a-la spring и тд. AC>Насколько я понял, autowiring это возможность позволяющая автоматически заполнять поля объекта ссылками на другие объекты, для того чтобы сделать их доступными в контексте объекта. В КОП используется другой механизм, чтобы сделать один компонент доступным другому, необходимо соединить(подключить) их интерфейсы.
Я программист, я не хочу ничего писать, я хочу юзать готовое!
L>>Механизма интроспекции мною замечено небыло. AC>Непосредственно ЯП не поддерживается, но может быть реализована, например в виде интерфейса IComponentInfo.
Я программист, я не хочу ничего писать, я хочу юзать готовое!
AC>Управление ресурсами (кроме памяти) по идее должно выполняется компонентами, ответственными за эти ресурсы. Освобождение ресурсов в таких компонентах может выполнятся в деконструкторе, автоматически вызываемом при разрушении компонента.
Я программист, я не хочу ничего писать, я хочу юзать готовое!
AC>Без проблем реализуется: один из компонентов — общая шина.
Я программист, я не хочу ничего писать, я хочу юзать готовое!
L>>есть поддержка сложной динам. диспетчеризации, AC>Что имеется ввиду?
Я имел ввиду IDispatch.
L>>есть поддержка многопоточности(аппартаменты/маршалинг и все такое). AC>Хочу сделать многокрасочность как в Go: каждый вызов функции в новом потоке.
Это что-то странное, AFAIK, go так не работает. Там есть пулл потоков, но методы по дефолту не пушатся в пулл потоков, это не эффективно же!
AC>Да, COM хорошая штука, но он бинарный и он сложен в использовании.
Так у вас тоже не просто все. COM компоненты гораздо проще писать на .net например. И даже на С++ в студии, с использованием визардов и библиотеки ATL тоже не сказать что очень сложно. Но, по крайней мере COM существует в реальности. Поддерживается инструментами разработки. Многие продукты умеют работать как COM-сервер, например тот же MS Word. Поэтому, имеет смысл либо использовать COM, либо, обеспечить interop с ним.
Re[10]: Заметка: Компонентная философия и реализация
L>Connection, в голове любого программиста, это соединение по какому-нибудь протоколу, которое умеет send/recv/close/shutdown. Код, который знает детали протокола обмена обычно вызывает эти методы, обмениваясь данными с удаленным хостом. Не понимаю как это "не нужно управлять".
Очень просто — Connection'ом управляет компонент который подключен к IData.
AC>>Достаточно просто, упаковать все составляющие компоненты в сборку, и можно работать с сервером как с монолитной, единственной сущностью. L>А зачем тогда все делается на компонентах?
Чтобы было возможно собрать сервер другой конфигурации, при этом не написав ни строчки кода.
L>Ну в статье идет речь о статических и динамических связях между компонентами, в разделе "управление памятью". Мне кажется делить связи по типам — излишнее усложнение.
Не, статическим и динамическими бывают компоненты. Первые это как-бы "скелет", они существуют всё время работы приложения(как например singleton'ы в ООП), вторые создаются по необходимости во время работы приложения.
AC>>В КОП используется другой механизм, чтобы сделать один компонент доступным другому, необходимо соединить(подключить) их интерфейсы. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Подключение/отключение интерфейсов это собственно и есть процесс "юзанья готового".
AC>>Непосредственно ЯП не поддерживается, но может быть реализована, например в виде интерфейса IComponentInfo. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Интерфейс IComponentInfo и его реализация, например могут быть унаследованы от прототипа Component(как в Java стандартные методы наследуются от класса Object).
AC>>Управление ресурсами (кроме памяти) по идее должно выполняется компонентами, ответственными за эти ресурсы. Освобождение ресурсов в таких компонентах может выполнятся в деконструкторе, автоматически вызываемом при разрушении компонента. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Деконструктор можно не использовать, если среда выполнения самостоятельно подчищает за вами(но это не очень хороший стиль).
AC>>Без проблем реализуется: один из компонентов — общая шина. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Ни каких проблем*.
L>Я имел ввиду IDispatch.
Нет такое не возможно(из соображений безопасности) и не нужно. Тип интерфейса всегда должен быть известен на этапе компиляции.
AC>>Хочу сделать многокрасочность как в Go: каждый вызов функции в новом потоке. L>Это что-то странное, AFAIK, go так не работает. Там есть пулл потоков, но методы по дефолту не пушатся в пулл потоков, это не эффективно же!
(погорячился, "как в" следует читать "на подобии")
Да, в Go нужно указывать что вы желаете запустить функцию в отдельном потоке. Здесь нужно будет указывать что вы желаете подождать завершения функции, т.е. по умолчанию функции будут вызываться в отдельном потоке(будет ли это действительно так решает компилятор(например, если функция "лёгкая", незачем для неё создавать отдельный поток) и рантайм(например, если в пуле отсутствуют свободные потоки, выполнится в контексте вызывающего)).
AC>>Да, COM хорошая штука, но он бинарный и он сложен в использовании. L>Так у вас тоже не просто все. COM компоненты гораздо проще писать на .net например. И даже на С++ в студии, с использованием визардов и библиотеки ATL тоже не сказать что очень сложно. Но, по крайней мере COM существует в реальности. Поддерживается инструментами разработки. Многие продукты умеют работать как COM-сервер, например тот же MS Word.
Москва не сразу строилась.
L>Поэтому, имеет смысл либо использовать COM, либо, обеспечить interop с ним.
В первую очередь я хочу сделать "interop" с Java.
*В случае если MatWorks (или другой разработчик) выпустит соответствующий фреймворк
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[22]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали:
V>>Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
ARK>Да, это все верно. Главное, чтобы работа с этими детерминированными линиями ошибки не слишком засоряла основной функционал (этого как раз пытаются обычно достичь с помощью исключений).
Обработка отдельного пина — это либо лямбда, либо вообще отдельный метод. Так что, никакого засорения "основного функционала" при обработке ошибок.
V>>Не забудешь, ты же его не опрашиваешь, он пришлет тебе в стиле push оповещение.
ARK>Ну на самом-то деле все равно где-то будет программный код — в описании функционала выходов. И в этом коде программист как раз должен "дергать" выходы другого компонента, возможно, при особых условиях.
Компонент "дергает" свои выходные пины и понятия не имеет, что затем происходит.
ARK>Например. Есть компонент с двумя входами — A и B, одним выходом — C. Значение C = A / B. ARK>Да, я могу запрограммировать C как "return (B != 0) ? (A / B) : 0", но я этого не хочу. Я хочу, чтобы C имел смысл только в случае, когда B != 0.
Я же уже говорил, ограничения на типы данных в реакцтивном программировании ничем не отличаются от ограничений на типы данных для "обычного" ФП или ООП. Предложи вариант решения твоей задачки для ФП или ООП и это решение так же подойдёт для реактивного программирования.
ARK>Таким образом, мы не можем подключить наш компонент как попало.
Это ты немного передёргиваешь с подбором слов для озвучивания своей мысли. Следуя той же логике, мы сейчас можем вызвать метод div(A, B) в любом языке из мейнстрима "как попало", потому можем подать на B ноль.
Но на этом прямо сейчас стоит вся индустрия... ))
ARK>Например, мы не имеем права поставить на вход B заглушку, подающую константу "0" (это не имеющий смысла пример, вырожденный случай) — программа не должна скомпилироваться.
Современные компиляторы довольно сносно выполняют распространение констант, поэтому подача константы 0 не интересна ни разу. Ну да, некоторые компиляторы догадаются предупредить о делении на 0. Зато, если мы прочитали этот 0 из файла, то на сегодня только системы с зависимыми типами способны гарантировать, что проверка на 0 будет выполнена перед вызовом div(A, B).
V>>А если тебе нужны ограничения — то можно задать ограничение на запрет "висячего" состояния этого пина в компоненте-источнике. )) И тогда, чтобы намеренно проигнорировать этот пин, тебе придется явно подключить к нему каку-нить заглушку.
ARK>Но ограничения могут быть более комплексными, чем просто запрет висячего провода.
Э, нет. Это разные виды ограничений. Мы рассмотрели ограничения на данные, а я говорил об ограничениях на подключения, согласно которой, запрещается игнорировать помеченные выходные сигналы.
V>>Некоторые компоненты могут давать сигнал ошибки, некоторые — нет. Например, сумматор может давать признак переноса, и ты можешь считать его согласно своей логики за ошибку (потерю значения) или нет, если это счетчик фазы, например, тогда переполнение до фени.
ARK>А вдруг компонент не просто выдает опциональный сигнал ошибки, а требует, чтобы этот сигнал нельзя было проигнорировать?
Ну вот и запрети ему "висячий" выход.
ARK>Ну, что в самом низу, для верхнего программиста не так важно. Разница в том, что исключение все эти штуки делает за сценой, плюс его нельзя проигнорировать, в отличие от кодов ошибок.
Как это нельзя игнорировать?
try { blah_blah() } catch {}
Это полный аналог предлагаемого "осознаного" подключения заглушки-игнора к механизму сигнализации об ошибке.
ARK>Maybe — это достаточно простая вещь, хотя и очень полезная. Кстати, а какие еще примитивные типы вы предполагаете использовать?
Я предлагаю использовать сколь-угодно сложные непримитивные типы. Всех ограничений — это отделить графы вычислителей от графов данных.
ARK>Но ограничения могут быть в теории гораздо более комплексные, чем maybe... Например, затрагивающие сразу несколько пинов.
Возможно. Но тут как в любой задаче — формулируй цель, доказывай её целесообразность и затем находи решение. Если ты выдашь такие требования, то некий конечный язык вполне может эти требования реализовать.
ARK>Да, это верно и для обычного программирования. Просто как-то мне кажется, что на реактивно-компонентную модель они могут лечь более естественно. Превращаются в этакие правила совместимости компонентов. Как разъем HDMI нельзя воткнуть в DVI.
При наличии возможности определять пользовательские составные типы данных это решается обычной типизацией:
data HDMI { RGB rgb; ... }
data DVI { RGB rgb; ... }
ARK>Да, и все-таки интересно было бы услышать ваше мнение по поводу двух вопросов из прошлого моего поста:
ARK>Изменяемое состояние у вас предполагается в виде "устойчивых состояний системы"?
Суть желаемого ограничения на типы-данные сводится к следующему: мутабельный тип — это явная ячейка для хранения иммутабельного значения.
ARK>Или будет какой-то аналог полей-атрибутов из ООП (во что слабо верится)?
Почему слабо? ))
Наоборот, мне требуется контроллируемая мутабельность. Но для её достижения предлагается очень простое ограничение — мутабельные переменные могут быть либо локальными переменными, либо полями "вычислителей", где сами графы вычислителей иммутабельны. Поля данных всегда иммутабельны.
Итого, получившаяся схема становится карйне подозрительно похожа на Хаскелевскую, где через чистое ФП сначала строится иммутабельный "вычислитель", а затем на нём выполняются "зацикленные" вычисления через монаду IO. Т.е. я вижу приближение к одному и тому же с разных сторон. Вернее так, понимание проблематики ПО всё больше заставляет программистов смириться с тем, что "железячные" наработки в любом случае будут диктовать моду в ПО. Пример принципа работы программы на "новомодном" Хаскеле тому пример: построили схему --> подали ей даные.
ARK>"Есть еще вот такой момент. Мыслю с точки зрения обычного ООП. Например, мне нужна в моем компоненте работа с файлом. Значит я должен ввести кучу пинов, к которым подключаю компонент, работающий с файлами. Т.к. все пины только примитивных типов, то их будет куча для каждого мало-мальски сложного объекта. Нет ли тут проблемы?"
Я думаю, что ты упустил тот момент, что я ни в коем случае не настаивал на том, что данные должны быть исключительно примитивных типов. Т.е. вопрос сразу теряет смысл.
ARK>Т.е. вопрос в том, не возникнет ли чрезмерного количества пинов у сложных компонентов из-за отсутствия абстрагирующих сложность сущностей типа ООП-шных объектов?
Гы-гы... Я наоборот уверен, что в обычном ООП, при наличии дешевого механизма "декомпозиции на атомы", мы бы давно пришли к тому, что кол-во слоёв в средней программе было не 2-3, а порядка 10-20. То бишь, вся программа была бы составлена из наипростейших/наипримитивнейших компонент (с большим уровнем вложенности, если рассматривать подробности). Прямо сейчас при попытке построить подобный дизайн мы получаем болезненный штраф за сумашедшую итоговую косвенность вычислений, отсюда и растут ноги "жирных" компонент — это из-за необходимости держать под контролем уровень косвенности вычислений.
Re[23]: Заметка: Компонентная философия и реализация
Во-первых, традиционно — спасибо за развернутый ответ.
V>Я предлагаю использовать сколь-угодно сложные непримитивные типы. Всех ограничений — это отделить графы вычислителей от графов данных.
Речь про комплексные рекорды-структы, без методов?
А если хочется инкапсулировать какие-то секретные данные? Можно, конечно, сделать что-то типа — объявить такой рекорд "Р" вместе с компонентом "К" внутри некоторого общего модуля "М", за пределами которого поля рекорда "Р" не доступны, а работать с ним можно только через компонент "К".
V>Я ждал этого вопроса давно и отвечал на него "предупредительно": http://www.rsdn.ru/forum/philosophy/4959771.1
V>Наоборот, мне требуется контроллируемая мутабельность. Но для её достижения предлагается очень простое ограничение — мутабельные переменные могут быть либо локальными переменными, либо полями "вычислителей", где сами графы вычислителей иммутабельны. Поля данных всегда иммутабельны.
Да, я это помню. Но это немного не то. Вопрос был — где хранится состояние.
Я так понял, что состояние хранится во внешнем "процессоре". Хотя это вопрос философский, где что хранится, зависит от точки зрения.
Если требуется сделать, например, стек или список — то для хранения состояния (массива элементов) придется замыкать входы на выходы, как в вашем триггере? Чтобы при следующем дергании входа "Add" с выхода предварительно считалось текущее состояние?
Остальное в общем понятно.
Кстати, я довольно давно читал про разработку — Акторный Пролог. Идея там заложена та же самая, что и в вашем подходе. За исключением того, что в основе там не ЯП общего назначения, а логическое программирование. Правда, очень многое не продумано, а реализовано так вообще криво. Ну что поделать, академический проект.
Это реализация в компонентном стиле(поверх ООП) третьего примера из заметки Компонентная философия и реализация на ЯП Scala.
В этом примере используется небольшой рантайм, реализующий некоторые из возможностей описанных в заметке, в частности сборку из компонентов и интерфейсы, а также(в некоторой степени) управление жизненным циклом компонентов. Вышло это всё довольно криво и многобуквенное(ибо натянуто на ООП и ФП), но тем не менее это работает
Вот так выглядит код собирающий приложение(отладочные сборки закомментрованы):
Скрытый текст
//Create named components
object Building extends Component {def main(args:Array[String]){}
val name = MMap[String, Component]()
/*Build program*/
//View
name += ("frame" -> new Frame(name))
name += ("viewDraw" -> new ViewDraw(name, "IWidgets", name("frame")))
name += ("statusBar" -> new StatusBar(name, "IWidgets", name("frame")))
//Matrix
name += ("space" -> new Space(name))
name += ("camera" -> new Camera(name))
connect("ILayout", name("space"), name("camera"))
connect("IViewDraw", name("viewDraw"), name("camera"))
//Game
name += ("arena" -> new Arena(name))
connect("IViewSettings", name("viewDraw"), name("arena"))
name += ("joystick" -> new Joystick(name))
connect("IFrame",name("frame"),name("joystick"))
connect("IControl",name("space"),name("joystick"))
connect("IControl",name("camera"),name("joystick"))
name += ("targetGen" -> new TargetGen(name))
connect("ITargetGen",name("targetGen"),name("joystick"))
connect("ITracking",name("targetGen"),name("joystick"))
connect("ITracking",name("targetGen"),name("arena"))
name += ("observer" -> new Observer(name))
connect("IAvatarWatch",name("observer"),name("joystick"))
connect("ITargetWatch",name("observer"),name("targetGen"))
connect("IStatusBar",name("observer"),name("statusBar"))
// /*Build test game*/
// //View
// name += ("frame" -> new Frame(name))
// name += ("testViewDraw" -> new TestViewDraw(name, "IWidgets", name("frame")))
// //Matrix
// name += ("space" -> new Space(name))
// name += ("testCamera" -> new TestCamera(name))
// connect("ILayout", name("space"), name("testCamera"))
// connect("ITestViewDraw", name("testViewDraw"), name("testCamera"))
// //Game
// name += ("arena" -> new Arena(name))
// connect("IViewSettings", name("testViewDraw"), name("arena"))
// name += ("joystick" -> new Joystick(name))
// connect("IFrame",name("frame"),name("joystick"))
// connect("IControl",name("space"),name("joystick"))
// connect("IControl",name("testCamera"),name("joystick"))
// name += ("targetGen" -> new TargetGen(name))
// connect("ITargetGen",name("targetGen"),name("joystick"))
// connect("ITracking",name("targetGen"),name("joystick"))
// connect("ITracking",name("targetGen"),name("arena"))
// /*Build test matrix physics*/
// //Manager
// name += ("testManager" -> new TestManager(name))
// //View
// name += ("frame" -> new Frame(name))
// connect("IFrame",name("frame"),name("testManager"))
// name += ("testViewDraw" -> new TestViewDraw(name, "IWidgets", name("frame")))
// //Matrix
// name += ("space" -> new Space(name))
// connect("IControl",name("space"),name("testManager"))
// name += ("testCamera" -> new TestCamera(name))
// connect("IControl",name("testCamera"),name("testManager"))
// connect("ITestViewDraw", name("testViewDraw"), name("testCamera"))
// connect("ILayout", name("space"), name("testCamera"))
// //Objects
// name += ("obj1" -> new TestObj1(name))
// name += ("obj2" -> new TestObj2(name))
// /*Build test matrix texture*/
// //Manager
// name += ("testManager" -> new TestManager(name))
// //View
// name += ("frame" -> new Frame(name))
// connect("IFrame",name("frame"),name("testManager"))
// name += ("viewDraw" -> new ViewDraw(name, "IWidgets", name("frame")))
// connect("IViewSettings",name("viewDraw"),name("testManager"))
// //Matrix
// name += ("space" -> new Space(name))
// connect("IControl",name("space"),name("testManager"))
// name += ("camera" -> new Camera(name))
// connect("IControl",name("camera"),name("testManager"))
// connect("IViewDraw", name("viewDraw"), name("camera"))
// connect("ILayout", name("space"), name("camera"))
// //Objects
// name += ("obj1" -> new TestObj1(name))
// name += ("obj2" -> new TestObj2(name))
}
Мнения и конструктивная критика приветствуются!
PS: Если вы с чем-то не согласны, пожалуйста не ленитесь написать с чем именно. Интересно же!
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
AC>Мнения и конструктивная критика приветствуются!
Совсем-совсем ни каких мыслей?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
AC>read more>>>
Знаете, вот недавно сам пришел к выводу, что подобная технология, на мой взгляд — самый грамотный вариант программирования. Мне нравится наличие небольшого количества общих концепций и в целом последовательность.
Лично я бы дал возможность вкладывать компоненты друг в друга, как микросхемы.
И, наверное, запретил бы полностью динамическое создание/удаление компонентов.
Хотя со вторым вариантом возникает вопрос — как быть, если мы хотим, к примеру, создать "форму" по XML-описанию из файла? Или создать два экземпляра одной формы? В этом случае получается, что нам нужны stateless-компоненты, которые будут принимать состояние параметром и работать с ним. А в другом случае окажется, что удобнее работать с инкапсулированным внутри компонента состоянием. Иметь два типа компонентов на все случаи жизни как-то накладно, а что тут еще можно придумать, пока не знаю.
Плюс еще непонятно, в каком виде будет представляться это самое "внешнее состояние" — оно должно хранить всю иерархию состояний вложенных компонентов, причем их состав в каждом случае будет разным. Короче, в этом месте как-то сложновато.
Re[2]: Заметка: Компонентная философия и реализация
ARK>Лично я бы дал возможность вкладывать компоненты друг в друга, как микросхемы.
Я для этого планирую использовать сборки, они снаружи как компонент(т.е. работа с ними не чем не отличается от работы с компонентами), но внутри состоят из компонентов.
ARK>И, наверное, запретил бы полностью динамическое создание/удаление компонентов. ARK>Хотя со вторым вариантом возникает вопрос — как быть, если мы хотим, к примеру, создать "форму" по XML-описанию из файла? Или создать два экземпляра одной формы? В этом случае получается, что нам нужны stateless-компоненты, которые будут принимать состояние параметром и работать с ним. А в другом случае окажется, что удобнее работать с инкапсулированным внутри компонента состоянием. Иметь два типа компонентов на все случаи жизни как-то накладно, а что тут еще можно придумать, пока не знаю. ARK>Плюс еще непонятно, в каком виде будет представляться это самое "внешнее состояние" — оно должно хранить всю иерархию состояний вложенных компонентов, причем их состав в каждом случае будет разным. Короче, в этом месте как-то сложновато.
Зачем гадать? Вы можете запилить своё КОП с вложенностью и статическими компонентами, модифицировав существующий движок. Поиграть с ним и посмотреть что получится.
Я ,например, использовал этот движок в одном небольшом приложении, и нашел что не хватает хорошей, надёжной потоковой модели (~6/10 проблем, были проблемами с синхронизацией).
PS: В этой заметке я описал наиболее свежую модель парадигмы (если вы ещё не читали), в будущем планирую развивать проект в этом ключе.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
— а здесь: http://simulators.narod.ru/sedov.zip — архив с текстовым файлом, где автор сайта поделился древней фидошной перепиской с неким товарищем А. Седовом, который представил свою "машину теорий" — вычислительную среду на базе таблиц решений и фортоподобного языка. Интересное чтиво по поводу моделирования систем и современного ООП, КОП и прочего программирования.
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Рискну отметиться по своим разработкам.
Текстовые, графические, а у меня еще и табличное представление это лишь представление. Языки устаканятся в единый синтаксис. В синтксис не только как текстовое представление, а как выражение сущностей. Так проще понимать. Объединяться парадигмы фунциональные, императивные и прочие.. Из объектной парадигма станет субъектной, что объединит и все настоящие и будущие парадигмы являясь к тому же метаязыком формирующим понятия для манипулирования.
, потому что, именно это я подразумеваю под "реактивное программирование".
можно выразить вообще весь design by contract. С++ относится к системе типов Лw.
