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>>
