Все новости от 13 марта 2002 г.

Новый взгляд на компонентные технологии

Между тем хотелось бы когда-нибудь увидеть воплощение интуитивного восприятия словосочетания «компонентная технология» как способа построения систем из компонентов, соединенных между собой посредством разъемов. Современное программирование давно доросло до понимания того, как реализовать подобную идею. Роль разъема может взять на себя интерфейс, т.е. абстрактный виртуальный класс, причем информация об иерархии наследования для интерфейсов может быть занесена в пользовательскую систему, например в реестр Windows.

Попробуем вообразить себе более подробно реализацию такой системы. Пусть для каждого компонента указано, клиентом каких интерфейсов он может (или должен) являться. Назовем такие «пустые места», т.е. требуемые интерфейсы, клиентскими разъемами. Если компонент предоставляет какие-либо интерфейсы для внешнего использования, они могут быть названы серверными разъемами. Так сами собой появляются правила соединения разъемов:

1. Клиентский разъем некоторого класса совместим с серверным разъемом того же класса (т.е. может быть подсоединен к нему).
2. Если классы различны, то для совместимости необходимо, чтобы класс серверного разъема был потомком класса клиентского разъема.

Чем хороша подобная технология, так это широтой спектра применения. Декомпозицию на компоненты (я назову их t-компоненты, true components) можно осуществлять для программ совершенно различного происхождения: от операционных систем (тогда функциональность компонентов будет заключена в объектных файлах некоторых распространенных форматов) до офисных приложений (в этом случае, как и в COM, можно будет использовать динамически загружаемые библиотеки).

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

Уровень 1. Библиотеки — самый глубокий уровень. Наиболее сильные программисты трудятся здесь. Сложнейшие концепции и технологии рождаются и умирают здесь, но иногда им удается пробраться на...

Уровень 2. t-компоненты — средний уровень (сейчас ему соответствует уровень отдельных приложений, апплетов или компонентов ActiveX). t-компоненты могут быть бинарными, поэтому ничто программистское не поднимается отсюда на...

Уровень 3.Системы. Соответствует низкому уровню подготовки программиста (сборщика), вплоть до ее отсутствия. Знание методов и концепций программирования здесь не нужно, достаточно прочитать документацию на доступные детали (компоненты). Тем не менее на этом уровне будут работать целые компании, поскольку и на знании готовых компонентов можно делать деньги.

В наше время зачатки такого подхода уже видны в таких популярных инструментах, как Delphi или C++ Builder. Например, там можно собрать простое приложение для работы с базами данных, не написав при этом ни строчки кода.

Автор работает программистом с 1995 года; специализируется на промышленных системах и системах реального времени.

Обсуждение и комментарии

	bosm - bosmmail.ru 13 Mar 2002 11:16 AM
см. также http://www.delphikingdom.com/article/sod.htm
	RoN - rodionlenta.ru 13 Mar 2002 11:30 AM
Что за гонево.... ????
	Qrot 13 Mar 2002 11:59 AM
вот такое вот гонево :) автор наверно раньше филологом был :)
	PTO - kruchkovkgb.ru 13 Mar 2002 12:33 PM
IMHO: автор все еще живет в прошлом веке, да и плохо понимает что такое COM и что такое Java... один перл про IUnknown чего стоит... молодца... Думаю ЗДНетовцам пора уже отказаться от использования труда россейских "аналитиков"... что не статья, так как будто Хазанов выступает. Пишет про будущее, которое уже давно наступило и уже заканчивается
	Valeriy - valeriyy2kmail.ru 13 Mar 2002 12:36 PM
Заманчиво получается -- сел и за пару минут наваял левой задней ногой прогу, и продал заказчику. А в свободное время можно заняться рассуждениями :) Только где же взять столько программистой ваяющих тучи компонентов на все случаи жизни?
	Vasilisk - vasiliskclubpro.spb.ru 13 Mar 2002 12:50 PM
Если действительно интересует теория "этого дела", то вот тут http://clubpro.spb.ru - её значительно больше
	bosm - bosmmail.ru 13 Mar 2002 12:51 PM
Насчет "прошлого века". Очень смешно смотреть на пыхтенье нынешних "бизнесменов" от программирования, которые не разобрались еще с локальным устройством как следует, а уже .НЕТы делают... Просто ну очень смешно. Ничего, все к нему вернутся погодя чуть-чуть, когда пыл-жар схлынет. Да, по тематике моя статья - прошлый век... который еще не завершился и когда-нибудь об этом напомнит. Армия программеров не нужна, достаточно переделать под t-компоненты существующие библиотеки, это вполне осуществимо. Насчет IUnknown и всего прочего - неконструктивно, поэтому и спорить не буду.
	PTO - kruchkovkgb.ru 13 Mar 2002 12:58 PM
2 bosm: конструктивно говорите... ну ок 1. обоснования того, что COM сделан (разрабатывался) для интерпретаторов 2. как это видно из устройства базового интерфеса IUnknown 3. вы когда-нибудь слышали про корбу да соап с визделем? 4. вы про .НЕТ слышали чего-нить? 5. вы знаете что джава не есть компонентная модель 6. вы вкурсе, что то, о чем вы пишите как о будующем и крутой теоритической проблеме уже много-много лет решено и все так работают пользуюясь компонентами и клеем в виде Дельфи, ВБ и прочего и что сейчас уже не стоит проблема "разобраться с локальным устройством", а все силы "нынешних бизнесменов" из всех лагерей брошены на интеграцию систем, компонентов и интерфейсов на разных платформах и в разных технологиях...
	Влад - GeraskinVladmail.ru 13 Mar 2002 1:22 PM
На мой взгляд статья написана очень непонятно. Не сложно, а именно непонятно. Я так и не понял, что же в конечном счёте хочет сказать автор, то ли 'помирить' два подхода к реализации компонентной технологии (OCX96 и CORBA), то ли предложить свой абсолютно другой способ реализации. Может быть желает создать надстройку над уже готовыми компонентами. Понятно только, что данная идея должна поддерживаться ОС, а это предложение уже к Microsoft'у. Мне кажется, что и Sun и Microsoft будут возражать против любого из вышеперечисленных вариантов. Насчёт IUnknown... Пожалуйста гн. Бинеев, если возможно, замените это нехорошее английское слово на IDispatch или на неменее хорошее русское слово: Disp интерфейс, я уверен, что тогда будет значительно лучше. Не обижайтесь. :)
	ASTeC - astecner-developer.info 13 Mar 2002 1:40 PM
причем информация об иерархии наследования для интерфейсов может быть занесена в пользовательскую систему, например в реестр Windows. === Похоже на анахронизм. Дядьки из MS наоборот отходтят от реестра в .NET и это здорово (куча преймуществ не вдаваясь в подробности - достаточно почитать www.gotdotnet.ru) Насчёт каких то там уровней где "не нужны навыки программирования или нужны программисты с низкой квалификацией": конечно создать какой нибудь калькулятор так можно. А вот написать конфигуратор компьютора для e-shop это уже наврядли. И хорошей программист всегда имеет аналитическую жилку. А аналитик не может быть хорошим если не знаком с практикой программирования. ИМХО. ЗЫ А как мне тиснуть сюда статейку? Сюда пишу тока "по знакомству" или как? А то я бы тоже мог пару "витиюшек" написать =)
	Mishka - mcsdonego.ru 13 Mar 2002 1:52 PM
Моё мнение на сайте RSDN: http://www.rsdn.ru/forum/message.asp?mid=34965
	Noname 13 Mar 2002 2:20 PM
Автору следует почитать о Java Beans, он бы понял, что ничего нового не сказал. И хватит приплетать Delphi к месту и не к месту. Приходит ламер и в оправдание своей некомпетентности или очередной "идеи" сразу начинает на что-нибудь ссылаться.
	Null - kurantvologda.edu.ru 13 Mar 2002 2:39 PM
Вот еще один чувак открыл Америку! Излагать собственное понимание проблемы и философствовать на эту тему конечно же хорошо, но для этого следует быть хотя бы немножко компетентным в обсуждаемой проблеме. Как недостаток всех гуманитариев -- нихрена не знают, зато со всеми понтами рассуждают.
	Редакция - infozdnet.ru 13 Mar 2002 2:54 PM
ASTeC: >А как мне тиснуть сюда статейку? Сюда пишу тока "по знакомству" или как? А то я бы тоже мог пару "витиюшек" написать =) Милости просим! http://zdnet.ru/?ID=175300
	RoN - rodionlenta.ru 13 Mar 2002 3:48 PM
А как информация об иеархии интерфейсов заносится в реестр ???
	Svyatoslav - ivantsivinter.net.il 13 Mar 2002 3:59 PM
Vopros k avtoru (ya viju sho on vstupil v diskusiyu): s promyshlenymi sistemami vse ponyatno, eto ponyatie slishkom obshee. Menya interesuyet kakaya svyaz' mejdu sistemami realnogo vremeni i COM, Java? Izvinyayus' za latinskij shrift - moj computer ne podderjivayet kirilitsu.
	Noname 13 Mar 2002 4:45 PM
2RoN: Наверное через GUID. Только если на всякую билибирду тратить идентификаторы, даже их (длинные) надолго не хватит.
	bosm 13 Mar 2002 5:05 PM
Несколько неудачно выразился "Java и COM - компонентные технологии". Можно было сказать "основа для создания компоненых технологий", но получилось бы слишком длинно. Конечно, вы правы, Java - язык (содержащий компонентную модель), COM - просто компонентная модель, JavaBeans и т.п. - компонентные технологии - строятся на их основе. Ничего плохого я в этом не вижу, просто предлагаю _другую_ основу для построения компонентной технологии. Теперь о .NET. Ничего не имею против нее. Никоим образом ее не отрицаю и с ней не спорю. И моя идея тоже ничего здесь не отрицает. В статье .NET даже не упоминается. По поводу того, что все это "давно уже решено" я не согласен - компонентные модели (как я уже писал) - созданы с намерением использовать их в алгоритмических языках. То, что предлагаю я, не обязательно должно использоваться в алгоритмических языках (хотя может использоваться и в них). Отвечая Mishke: вы меня несколько неправильно поняли. Я не предлагаю механического наследования. Все "наследование" будет осуществляться как обычно, программистами - создателями компонентов. В системе будет лишь регистрироваться информация о иерархии. Если слово "реестр" является для кого-то красной тряпкой, могу выразиться иначе: иерархия должна быть известна системе исполнения или сборки (в зависимости от реализации), а где она будет храниться уже не так важно. Позволю себе так же заметить, что правота не определяется тем, какое слово вы знаете - IUnknown или IDispatch, а тем, к месту ли оно произносится. IUnknown (как бы некомпетентен я в этом ни был) является основой COM, а IDispatch - всего-лишь настройка, причем, как все вы прекрасно знаете, не обязательная для вызовов методов интерфейса из интерпретируемых языков. По поводу моей некомпетентности ... я бы не был так резок по отношению к Вам. :)) Спасибо за бурное обсуждение.
	PTO - kruchkovkgb.ru 13 Mar 2002 5:18 PM
2 bosm: это усе лирика, там внизу вопросиков немного было, не могли бы вы ответить на них по-пунктно... а потом поговорим. я вот еще раз перечитал статью сию и все никак не могу увидеть чего ж такое интересное предлагается? что там за локальная машина? и далее про алгоритмические языки... ну есть к примеру возможность из ЛИСПа дергать объекты СОМ и даже слышал для Корба, он не алгоритмический... вы эта пальцем покажите практическое применение своих идей, а то пока я вижу только кистень (с) Шарапов.
	bosm 13 Mar 2002 5:43 PM
По формальной классификации ЛИСП - функциональный язык. Но в нем можно писать алгоритмы, еще как :)). Я же предлагаю "не использовать клея, кроме клея", Валерий правильно меня понял. Т.е. строить систему, просто соединяя разъемы компонентов, и делать эти соединения не только очевидными для _пользователя_, но и давать ему возможность изменять готовую систему, встраивая в нее другие компоненты с совместимыми интерфейсами (буде такие найдутся). В этом (в открытости структуры, хотя бы поверхностной, для пользователя) и состоит основная идея. В том что открывать, как открывать и как к этому подготовиться чтобы это было _безопасно_. Открывать готовый алгоритм для изменения _опасно_ (преступно :)), открывать "детали, соединенные разъемами" вполне возможно. Я считаю это правильным и перспективным. Кроме того, Валерий, никто при построении системы не обязывает Вас обходиться только уже имеющимися компонентами - пишите их сколько угодно с помощью привычных средств сами. Но структуру приложения откройте для просмотра и изменения. Конечно, открытость структуры приложения - не новая идея. Я предлагаю лишь радикальное и _безопасное_ средство это сделать.
	Mishka - mcsdonego.ru 13 Mar 2002 5:59 PM
К автору: дайте мне пример компонентов и их дальнейшей сборки, кода не надо, никакой конкретики тоже, просто чистые абстракции, то бишь как Вы это сами видите. То есть вроде: берём компонент "Писалка", берём компонент "Рисовалка", объединяем получаем "Visual .NET HTML Editor 4.0".
	RoN - rodionlenta.ru 13 Mar 2002 6:12 PM
2 Noname: Ну, регистрация COMпонентов и Iнтерфейсов в реестре не имеет никакого отношения к "иеархии интерфейсов". А интерфейсы и вообще регистрировать не обязательно - это только для получения SCM-ом информации для маршалинга требуется. И GUID-ов хватит на всех, дело не в их длине, а в алгоритме их генерации. И вообще, ну его нафиг флеймить над пустой статьёй - есть поинтереснее занятия.
	MB 14 Mar 2002 1:04 AM
Новизна статьи устарела по меньшей мере на 7-8 лет. Это ужасно, что редакция zdnet не фильтрует подобную аналитику.
	bosm 14 Mar 2002 2:24 AM
"Новизна устарела" - интересное замечание, но хотелось бы услышать обоснования. Да, компонентные модели были созданы давно. Но попыток сделать то, что предложено мной, я не припомню. Это первое. РоНу - Вы правы, сегодняшняя регистрация компонентов и интерфейсов в реестре не имеет отношения к тому, что я предлагаю. Теперь все-таки: что же я предлагаю. Я предлагаю безопасный способ приоткрыть структуру приложения пользователю (определенным группам пользователей), не открывая при этом код. Открыть как для просмотра, так и для изменения. Я предлагаю конкретный механизм - как это сделать. Никакой критики других компонентных технологий не выдвигаю, просто говорю о том, что они выполняют иные задачи. Новизна очевидна, поскольку таких систем (по функциональности) просто не существует. Конструктивной спора по поводу этой идеи здесь пока не было. Выдвигалось 2 типа аргументов: 1. да он ламер 2. статья устаревшая Misha, я постараюсь ответить на Ваш вопрос на RSDN. Спасибо всем.
	lope de 14 Mar 2002 3:12 AM
э а чо вы намужика набросились ? вот где клоуны то собрались.. норамльная идея - открыть структуру проги ламеру да так чтоб не ламернулся.. и не новая кстати. зря про комы с джавами начал это для ниъ тряпка красная точно. а реализаций удачных не было пока да
	RoN - rodionlenta.ru 14 Mar 2002 9:32 AM
Имхо, доля истины в отношении к новым технологиям есть. За последние несколько лет бешеное количество средств и усилий потрачено на освоение всяких комов, аспов, скрипт-хостингов и т.д. и т.п. Приходит в мастдай какой-то "гуру" хренов, который раньше дельфи лабал, и теперь выясняется, что всё что люди делали - говно, надо выкинуть, а вот точка-нет рулит - все на неё. Тепепрь что же это, опять переучиваться, тратить несколько з/п на книжки-учебники, сидеть ночами и т.д. а к тому времени придёт ещё какой-нибудь "гуру мастдая" и скажет, что точка-нет - говнище и отстой, а вот, какая-нибудь "запятая-нот" - это полный рулез, и опять надо всё бросить и переползать на неё. Что-то с этими рантаймами-фреймворками MS в моих глазах подзасрался. Я уже даже подумываю - не переходить ли на *никсы.
	Qrot 14 Mar 2002 11:14 AM
2bosm: мысли, подобные изложенным, приходят в голову каждому, кто впервые сталкивается с COM или CORBA - ах, как хорошо было бы, если бы можно было бы лепить аппликухи из готовых компонентов, как из конструктора. И народ постепенно движется в этом направлении - взять хотя бы использование COM-компонент из скриптовых языков, когда скрипт используется только для связывания компонент, а логика уже спрятана внутри этих компонент. Что такого нового было предложено в статье? Да ничего, ИМО! И какого обсуждения Вы тогда хотите? Вы что, ожидали, что Вас назовут гением? Я, честно говоря, не понял, для чего была сия публикация... Ниже Вы сетовали на отсутствие конструктивного спора. Какой может быть конструктивный спор, если Вы игнорируете вопросы, Вам задаваемые, и продолжаете пересказывать свою статью с завидным упорством. В самом начале Вам было задано несколько вопросов - не мной, но примерно эти же вопросы хотел задать и я. Вы будете на них отвечать? Иначе это не обсуждение, а монолог автора.
	Qrot 14 Mar 2002 11:25 AM
2RoN: ты как то совсем расстроился, я смотрю :) ИМХО, все технологии, особенно новые, нужно рассматривать через призму своих текущих задач - насколько они соответствуют. До сих пор полно народу, пишущего под DOS - и ничего, имеют свои деньги. Так что забей ты на этот фреймворк - что нового он даст тебе и твоему проекту? я, например, с ATL3/WTL еще долго не слезу - не вижу смысла абсолютно.
	Vasilisk - vasiliskclubpro.spb.ru 14 Mar 2002 11:27 AM
<b>13 марта, 2002, 17:05 - bosm Несколько неудачно выразился "Java и COM - компонентные технологии". Можно было сказать "основа для создания компоненых технологий", но получилось бы слишком длинно. Конечно, вы правы, Java - язык (содержащий компонентную модель), COM - просто компонентная модель, JavaBeans и т.п. - компонентные технологии - строятся на их основе. Ничего плохого я в этом не вижу, просто предлагаю _другую_ основу для построения компонентной технологии </b> Почтеннейший, в том-то и дело, что Вы ничего не то, что нового, а даже и просто consistent в инженерном отношении не предлагаете. По многим и многим постулатам Вашего предложения хочется заставить Вас разоблачить самого себя. Т.е. предложить Вам всего-лишь внятно ответить на вопросы "как именно" и "почему", спустившись с "философии" на позицию нормального инженера, который "не стратег". Если Вы дадите себе труд немного развить Вашу теорию в сторону реализации, да ещё перед этим кое-что почитаете из имеющегося вокруг (и до Вас ведь существовало программирование и программисты? Про Страуструпа и его изобретение, например, слышали?), то Вы сами же и обнаружите эти обстоятельства... Чтобы не быть голословным объясните мне, тёмному, пожалуйста про IUnknown - почему его конструкция выдаёт его "интерпретаторскую направленность" и как именно нужно бы сделать "правильно"? И - почему именно. Тут не нужно знать COM, тут просто нужно быть программистом, т.е. понимать отношения предметного мира в котором программист работает. А вы - программист, т.е. как я уверен, Вам нужно только сесть и написать ответ. Касательно же философии и пр. Вы ничего не слышали про такую штучку, как CORBA? Отраслевой стандарт, между прочим. Не одна голова разрабатывала, не один критический штурм _концепция_ выдержала. Да и COM сюда тоже можно смело отнести - он просто-напросто Вашу концепцию целиком включает в себя как _один_из_ своих, совсем примитивных, способов компонентного взаимодействия. Понимаете, в чём беда - COM, который Вы считаете только "основой компонентной технологии" ... сам больше Вашей концепции более высокого уровня, чем COM :(
	PTO - kruchkovkgb.ru 14 Mar 2002 11:53 AM
2 bosm: какой конструктивной критики вы хотите... честное слово напоминает надувшегося вовочку ругающего свою учительницу за то, что она поставила ему двойку за ответ по географии, когда он америку показал в китае и монголию в австралии... училка ставит 2, но Вовочка все "нет, дураком меня назвать каждый может", вы конструктивно критикуйте... Конструктивно училка может сделать следующее - вызвать родителей в школу или оставить вундеркинда после занятий и лично ему показать на карте где какие страны есть... т.е. в вашем случае либо объяснять вам почему ваш перл про IUnknown дурь на пальцах пересказывая вам книжки по КОМ, читать лекцию про Корба... второй вариант позвонить вашему начальству и попытаться объяснить что пора человека с небес теоритического программирования спускать на землю, чтобы он вместо теорий построения универсального велосипеда сидел и крутил педали тех великов, что уже понаделали люди гораздо более понимающие в велосипедах.
	lope de 14 Mar 2002 12:05 PM
COM включает мою модель? Вот это утверждение. Ну ка, докажите? Василиск, у Вас интересная последовательность рассуждений: сначала вы говорите о том, что я ничего нового и естественного не предлагаю, а потом, как бы в доказательство, предлагаете обсудить вопрос, выдранный из начала статьи: почему, мол, IUnknown ведет к интерпретируемости. Хорошо, отвечу насчет IUnknown (хотя к основной идее статьи это не имеет отношения): я думаю, нетрудно, имея воображение, представить себе как появилась COM, и именно из структуры IUnknown. Предположим, вы решили предоставить сторонним разработчикам возможность делать классы объектов для Вашего интерпретатора. Ах, черт, а как же мы будем отслеживать существование этих объектов?! Давайте введем подсчет ссылок в некоторый базовый интерфейс, а разработчиков обязуем наследовать от него! То, что разделили идеи интерфейсов IUnknown и IDispatch, возможно, и привело к созданию отдельной - и неплохой - технологии. Это не моя идея, да ссылку не найду. Впрочем, может быть я и ошибаюсь, но на консистентности моей модели это никак не сказывается :)) Мне тут и там предлагают к рассмотрению CORBA и .NET, говоря что там это уже все реализовано. Причем никто никак это не пытается доказать. Кроме того, не учтен один момент: мою модель можно будет использовать даже при построении систем "на голом железе", т.е. без операционок, и даже для построения ядра операционки. И еще: какое изобретение Страуструпа Вы имеете в виду? У него их немало, помнится. Отвечаю на _остальные_ вопросы PTO: 3. Про CORBA, SOAP и WSDL слышал. Я предлагаю (внимательно!) не МОДЕЛЬ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ С ИСПОЛЬЗОВАНИЕМ КОМПОНЕНТ а КОМПОНЕНТНУЮ МОДЕЛЬ, которую можно (но не обязательно) развить на основе COM. 5. Java не компонентная модель, однако ее содержит. 6. Много лет как решено - не согласен. Докажите? Теперь: что нового я предлагаю по отношению, например, к Automation (как все быстро забыли это слово, а?). Я предлагаю сделать явной и доступной к изменению структуру приложения, причем сделать это безопасно. Скриптовые решения, при всем моем уважении, такой возможности не предоставляют. Конкретную реализацию разрабатываю в настоящее время.
	bosm 14 Mar 2002 12:07 PM
Извините, предыдущее высказывание принадлежит мне - просто просто мы с товарищем пересеклись на одном компе...
	lope de 14 Mar 2002 12:11 PM
да хрен с ними извинятся еще.. было бы перед кем
	PTO - kruchkovkgb.ru 14 Mar 2002 12:38 PM
2 lope de: угу... поддержи начальника 2 bosm: ну и кому нах нужна компонентная модель расчитанная на локальную машину, когда уже есть более лучшая модель, которая еще и распределенно может работать... А про IUnknown вы похоже не поняли и про счетчик тоже... как и не просветили почему же оно для интерпретатора было сделано. Короче, в сад, читать книжку Inside COM, потом поговорим.
	Mishka - mcsdonego.ru 14 Mar 2002 12:50 PM
"...как появилась COM, и именно из структуры IUnknown." Я пас. Хотелось как лучше, получилось как обычно. Уважаемый господин Бинеев напишите Вы книгу по компонентной модели, станете в один ряд с Бучем, Страуструпом, Фаулером и пр... если конечно Ваш труд будет признан широкими массами, но как показывает дискуссия, серая масса ещё не готова (или уже не готова) принять сию концепцию. За сим заканчиваю дискуссию и здесь и на RSDN.
	PTO - kruchkovkgb.ru 14 Mar 2002 3:33 PM
2 Vasilisk: За технику 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 За артистизм 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0 6.0
	Herman Zu - zuzinnppmera.ru 14 Mar 2002 4:18 PM
фигня это все, вот что я вам скажу. Я еще помню как боролись против goto, потом за объекты, потом за компоненты во всех прoявлениях. Все эти умозрительные гипотезы и классификации страшно далеки от принципиальной проблемы : КАК программу-то писать? По тому что сейчас программер работает как казахский акын - "Что вижу-о том пою" в смысле "пишу программу так, как я бы на ее месте делал вручную". А чтоб программа была надежной - нужно делать конечный автомат. Я вот программ надежнее чем сгенеренные yacc-ом не видал - а почему ? Конечный автомат ! А там ни те объектов ни компонент ни СОМ-а ... и goto на каждом шагу. И писал я прогу(парсер java) три часа. Нужна идея КАК надежные проги писать, а не классификация накопленного сорса Zu Программер с 1986 года
	RoN - rodionlenta.ru 14 Mar 2002 5:21 PM
Хм... Магазинный автомат в конечный можно развернуть, токмо если ограничение на размер магазина наложить, однако.
	RoN - rodionlenta.ru 14 Mar 2002 5:26 PM
А насчёт надёжности за счёт автоматизации разработки, насколько я наслышан, пока что попытки автоматизации верификации кода приводили к созданию верификаторов такой сложности, что для реального использования они сами нуждались в верификации :)) Кто побреет брадобрея, одним словом...
	Илья 14 Mar 2002 8:49 PM
Привет, всем! Не хочу никого оспаривать и устравивать полемику по поводу отдельных фраз. Хочу сказать только одно. Что еще в 98 году мы сделали систему, которая собиралась по очень по-хожему принципу. Клиенту поставлялся набор компонент. И в человек на месте мог собрать систему такой, какая она ему нужна. Информация о компонентах хранится в реестре(но это непринципиально). Существует отдельное приложение, которое создаёт структуру клиентского приложения. И отдельное приложение, которое эту структуру читает, и внутри которого клиентское прложение существует и работает. Сделано это все был с использованием идей COM. Только компоненты не регистрировались в реестре, не было фабрик. Все это мы опустили для простоты и, может быть, оригинальности. Естественно, эта задача не была всеохватывающей. Она была заточена под конкретную область. Так что идея действительно не нова. А вот о чем мы всегда думали, так это о поддержке такой системы. Дело в том, что, чтобы позволить человеку собирать самостоятельно систему из компонентов, его(человека) надо очень многому научить. В частности, он должен очень!!! хорошо представлять, что компоненты делают и какого рода взаимодействие между ними существует. Он должен понимать всю эту логику. Мне кажеться, что именно из-за сложности поддержки таких систем столпы этого бизнеса не производят таких систем.Хотя я могу и заблуждаться. Ну вообщем, так вот.
	MB 14 Mar 2002 10:42 PM
"Нужна идея КАК надежные проги писать, а не классификация накопленного сорса." 2 Zu: Очень точно сказано. И про yacc я согласен. Все равно, чтобы писать надежные проги нужно уметь собирать хорошо отлаженные компоненты или просто классы. 2 Бинеев: Reference Counting старо как мир и НИКАКОГО отношения не имеет ни к интерпретации, ни компонентам. См. реализацию Delphi Huge String. Тоже по вашему для интерпретации сделано? Ну как так можно? Сказали бы сразу, мол ошибся, имел в виду IDispatch... Вы меня расстраиваете... На тему. Согласен с Ильей. Идея очень не нова. Сам делал подобное несколько лет назад. Столкнулся с той же проблемой поддержки, о которой говорит Илья. Пришел к выводу, что: а) В большинстве случаев невозможно создать жесткий интерфейс не урезав сильно возможности настройки работы компонента, откуда... б) Event Handlers остаются актуальными, как гибкий способ стыковки-склейки, откуда... в) Чтобы стыковать компоненты в реальном мире нужно писать код и чаще всего этот код будет хотя бы немного вымороченным, так что писать его нужно будет умеючи, откуда и потом еще и отлаживать, откуда... г) нет в этой затее никакого практического смысла, увы. Людям нужны хорошие отлаженные и удобные программы. Ничего подобного вы на чистой стыковке не напишите. Я не вижу, чем ваша идея отличается от того, что УЖЕ ДАВНО реализовано в COM, Delphi, Java и мн. др. Тем не менее компонентную технологию, я считаю, таки да можно немного усовершенствовать, но это задача для гораздо более серьезного исследования... MB Тоже программер с 1988 года
	glassy 15 Mar 2002 2:45 AM
А где Skull с питоном под мышкой? Про yacc уже вроде сказали :)
	bosm 15 Mar 2002 4:00 AM
Сначала по поводу возражений по технологии. Статическое разбиение любой серьезной системы осуществляется всегда и всеми программистами, в меру их разумения. Иногда это разбиение остается в голове, иногда фиксируется с помощью CASE-средства. Все, что я предлагаю - это оставить статическую структуру программы видимой для пользователя и позволить ему изменять эту структуру. Я не предлагаю заставить программистов собирать приложения из купленных\скачанных компонентов, это неестественно (и в статье такое не предлагается). Более естественный путь - программа распространяется в виде "схемы" ее статической декомпозиции. По поводу IUnknown: это мое личное мнение - о том, как исторически возникла COM (а не о том, как потом все получилось на самом деле). Не думаю, что COM возникла как озарение у кого-то в голове в полном объеме и сразу. Скорее всего это постепенно шло от задач VB, хотя я могу и ошибаться. Подсчет ссылок - действительно древняя вещь, я же говорил о том, как эта вещь была применена для предоставления возможности программистам делать компоненты для VB. Я думаю, что исторически все происходило именно так, потом же преобразовалось в известную нам технологию. MB, я очень сожалею, что так Вас расстроил.
	selivan - selivanaha.ru 15 Mar 2002 4:05 AM
Разрешите мне тоже подключиться к обсуждению этой захватывающей темы... Я в общем тоже не понял, что такого кардинально нового предлагает автор в данной статье, но в последнее время мне постоянно приходит в голову следущая мысль... Все конечно же согласны с торжеством компонентной модели. Но при этом возникает другая проблема: как найти подходящую компоненту для своей предметной области для своей программно/аппаратной платформы? Проблемы: 1. несовпадение способа передачи параметров, да и типов самих параметров в разных компонетных моделях, 2. различные аппаратные платформы. Предлагается (давно уже не мной) следующий способ решения данных проблем: 1. Договориться о едином способе описания структурированых данных, и передавать список параметров между всеми (!!!) компонетнами в этом виде 2. Придумать способ вызова методов компонент не зависящий от платформы Ответы на данные вопросы: 1. XML, 2. SOAP Теперь другая мысль. В принципе любая программа занимается тем, что в процессе своей работы преобразовывает некие данные из одного состояния в другое (пользовательские интерфейсы мы здесь не рассматриваем, будем думать о серверной части). С определенного момента мы поняли, что чтобы преобразовать данные не обязательно писать программу (алгоритм), а достаточно декларативно записать правила преобразования (это не всегда возможно, но все таки часто). Так как все наши компоненты говорят на XML, то и преобразовывать данные мы будем с помощью XSLT. Может получиться так что при соединении двух компонент вторая требует немного другой схемы параметров чем результат выдаваемый первой компонентой, вот здесь-то мы и используем наш декларативный способ преобразования. Вполне может случиться что через N лет мы уже запрограммируем практически все алгоритмы на XML-компонентах и нам надо будет только соединять готовые XML-компоненты не используя никакого алгоритмического языка, а обходясь одним декларативным. Далее надо бы как-то описывать метаданные (параметры входа и выхода) для компоненты. Ну это просто, для этого компонента должна выдавать свою XSD-схему по вызову некоторого стандартно определенного метода (аналог IUnknown). Так что такие утопические мысли... Но мне кажется что все что я тут понаписал называется .NET, хотя место для развития у нее еще есть. ПС: Мне кажется пора стандартизовать способ вызова и способ передачи параметров для компонент в разных языках/платформах, так как не всегда хочется переписывать компоненту сортировки массива только потому, что ее нет для данной платформы или языка... Какие мысли? прошу высказываться...
	bosm - bosmmail.ru 15 Mar 2002 4:42 AM
Илья, не могли бы Вы написать мне, либо оставить свой e-mail?
	bosm - bosmmail.ru 15 Mar 2002 6:22 AM
еще пару слов насчет "перла про IUnknown". В книжках, которые мне тут все так советуют здесь прочитать, речь идет о современном состоянии COM и ее применений. Я же говорю о происхождении. 5-6 лет назад, читая одну из первых (и до сих пор лучших на мой взгляд) книг о COM я понял, что корни все-таки лежат не в "обеспечении удобства корпоративных разработок", как сейчас все это представляется, а в интерпертируемых языках (хотя IDispatch там появляется в конце книги). И я по прежнему думаю так. К тому, как сейчас используется COM, это отношения не имеет, конечно. Или вы хотите убедить меня в том, что не IUnknown - основной интерфейс для вызова VB? Если так, то спасибо, но мне это известно :)).
	bosm - bosmmail.ru 15 Mar 2002 8:37 AM
Очепятки: 1. "для вызова VB" - "для вызова из VB" 2. интерпертируемых - интерпретируемых 3. "тут ... здесь ..." - ну вы меня поняли :)
	RoN - rodionlenta.ru 15 Mar 2002 9:23 AM
К сведению всех присутствующих, кто ещё не знает, VB уже давным-давно не требует IDispatch для вызова компонента. RTFM.
	bosm - bosmmail.ru 15 Mar 2002 9:58 AM
> VB уже давным-давно не требует IDispatch для вызова компонента Да, я уже об этом писал здесь :)). Почитайте ниже: "IDispatch - всего-лишь настройка, причем, как все вы прекрасно знаете, не обязательная для вызовов методов интерфейса из интерпретируемых языков."
	ASTeC - astecner-developer.info 15 Mar 2002 10:25 AM
2selivan: Ты прав - это всё есть в .NET Включая поддержку разных языков и в принципе разных платформ: смотри проект Mono
	Илья 15 Mar 2002 11:29 AM
Про IUnknown. Модель COM, как известно, разрабатывала не сама Microsoft, а сторонняя контора, которая чуть раньше разработала CORBA. И если сравнивать эти модели, то видно,что местами они похожи, а местами координально отличаются в подходах. Можно предположить, что COM появилась вместе с CORBA, но, не выиграв сражения, оставалась невостребованной. Именно поэтому, как мне кажеться нет смысла говорить о интерпритаторской сущности IUnknown. К тому же, как мне кажеться, IUnknown прекрасно справляется со своими задачами в неинтерпритируемых языках. Непонятно, почему бы не исходить из этой предпосылки.
	bosm - bosmmail.ru 15 Mar 2002 12:01 PM
C учетом обсуждений и поправок, сделанных здесь и на RSDN, сформулирую все снова: 1. Статической объектной декомпозицией (SOD) программы я называю такое ее разбиение, при котором все компоненты существуют от начала и до конца работы программы. 2. Схему SOD программы или сложной системы можно было бы предоставить пользователям для просмотра и изменения. 3. Предлагается такое представление SOD, которое а. интуитивно понятно для пользователей б. приемлемо для программистов 4. Формулировка представления: система состоит из компонентов, соединенных посредством разъемов. Разъемы бывают клиентскими (требования компонентов к окружению) или серверными (предложения компонентов своему окружению). 5. Разъемы принадлежат классам разъемов, между классами установлено отношение наследования. Совместимость разъемов связана с наследованием так, как это описано в статье. Внутренняя структура разъемов не декларируется. Информация о иерархии классов хранится глобально по отношению к системе исполнения. Краткая формулировка идеи: приложение поставляется в виде схемы SOD-представления, созданной на основе модели "деталь-разъем".
	eXOR 15 Mar 2002 1:45 PM
2 bosm: А можно вопрос? Не является ли b2b частным случаем вашей идеи?
	Tonyman - formeau.ru 19 Mar 2002 3:33 PM
2 PTО Старый - ты один сечешь в СОМ как следует. А всякие лОхи типа bosma - напоминает детские рассуждалки, сразу видно что о СОМ только по книжкам знают...
	PTO - kruchkovkgb.ru 19 Mar 2002 8:13 PM
2 Tonyman: да нет, я бы не сказал что сильно секу... тут бывает народ и с гораздо более глубинными знаниями по этому поводу... а так все мы учимся по немногу, чему нибудь и как нибудь
	Qrot 19 Mar 2002 8:34 PM
что, РТО, поклонники появились? :))
	eXOR 19 Mar 2002 8:39 PM
2 Qrot: Ты чего.. я же его самый давний поклонник ;-).
	bosm 20 Mar 2002 3:36 AM
Друзья мои, я очень рад вашему тихому счастью. Может быть я и ошибся (малость) в терминах, но у меня за плечами проектирование, написание и отладка OPC-сервера для одной веселой компании. И еще несколько проектов, связанных с COM. Если не знаете, что есть OPC - поясню: это такой "простенький" промышленный стандарт передачи данных, основанный на COM. Можете ради интереса зайти и почитать спецификацию на http://www.opcfoundation.org/. То, что я написал в статье, не могло устареть, поскольку этого никто пока не делал. Хотя разговоры были, но дальше разговоров дело не пошло. CORBA, SOAP и другие красивые слова отношения к этому никакого не имеют. Если вы думаете иначе - либо вы невнимательно прочитали статью, либо не разбираетесь в вопросе. Тем не менее - еще раз спасибо всем.
	kostus - some2some.com 21 Mar 2002 7:26 AM
2bosm: Если смысл идеи в распространении программы в виде схемы, то всё равно возникнет вопрос сложности поддержки (хотя бы поставки ещё и компонентов), что неминуемо приведёт нас к мысли о всеобщей стандартизации (и не только интерфейсов, но и собственно компонентов, т.е. существующий-то код всё равно придётся переписать). Это уже давно решается несколько другими средствами, причём это вполне работоспособно (CORBA, например). Предположение 1. Вы же просто предлагаете вынести логику работы программы (приложения) из самой программы во внешний обработчик статически представленной схемы. Это не ново. Это есть интерпретатор. В самом деле, почему не рассматривать текст программы на, скажем, VB, как такую вашу статическую схему, а интерпретатор - как внешний обработчик схемы? Что здесь не так? Те же яйца, вид сбоку. Предположение 2. От центральной логики всё равно никуда не уйти :) Следствие. Вы говорите не о новой концепции, а о вашей собственной конкретной реализации уже существующих идей. Просто как раз об этом вы практически ничего и не сказали. P.S.: Впрочем, возможно, ваш IQ > 300, и я просто не в состоянии вас понять? :)
	bosm 21 Mar 2002 8:01 AM
2kostus: Хороший пост, спасибо. Отвечаю. Не знаю, возникнут ли большие сложности поддержки и стандартизации - по моему, все существующие стандарты несложно осуществить "над" моей схемой (в том числе и CORBA). Предположение 1 верно, но яйца (извините) другие. Программу на VB как раз нельзя рассматривать как статическую схему - обычно это нормальная алгоритмическая программа, иногда довольно сложная и, конечно, связанная с накладными расходами интерпретатора. В моем случае "интерпретируемая часть" будет выполняться только при запуске программы, только для соединения статических компонентов между собой. Т.е. потери производительности в ходе работы программы или системы не будут связаны со схемой соединения - ее задачей будет только лишь запуск. Все, что будет происходить потом, зависит уже от качества написания компонентов. PS: Думаю, Ваш IQ никак не меньше 140 :)). Хотя Ваше "следствие" все равно не совсем корректно.
	kostus - some2some.com 21 Mar 2002 12:00 PM
2bosm: Вопросы: 1. Насколько предлагаемое статическое ("декларативное") описание взаимодействий ("соединений") компонентов проще/сложнее алгоритмической программы? 2. Чем отличается соединение компонентов между собой от компиляции алгоритмической программы? Естественно, оба вопроса предполагают использование ООП и уже имеющихся технологий, реализующих компонентную модель. Так же положим, что мы читали Буча. Нет, идея в чём-то красивая. Как вообще красива идея компонентности. Но нужна-ли именно ваша реализация... В подавляющем большинстве случаев важна как раз логика взаимодействия компонентов. Именно логика взаимодействия является сложной частью программирования. Не вижу как ваша схема может упростить эту часть процесса программирования.
	bosm 22 Mar 2002 3:48 AM
> 1. Насколько предлагаемое статическое ("декларативное") > описание взаимодействий ("соединений") компонентов > проще/сложнее алгоритмической программы? Проще. Но в нем не будет выражена вся функциональность системы: лишь общая логика проекта. Как в системах проектирования, только с явным указанием требований компонентов к окружению. Основная функциональность будет заключена в компонентах. > 2. Чем отличается соединение компонентов между > собой от компиляции алгоритмической программы? Да всем. Это несравнимо более легковесный процесс. Несколько сотен присвоений (mov) и все. Если исключить парсинг, конечно. > Именно логика взаимодействия является сложной > частью программирования. Не вижу как ваша схема > может упростить эту часть процесса программирования. Я думаю, что статическое разбиение программы на части ("детали") осуществляется всегда. Иногда неосознанно. Иногда осознанно, но сразу воплощается в код. Иногда фиксируется с помощью какой-либо системы проектирования. Я лишь предлагаю явно выразить требования\предложения компонентов и топологию проекта, и оставить эту информацию видимой продвинутым пользователям и другим программистам. И даже позволить им вносить изменения.
	bosm 22 Mar 2002 5:05 AM
Кстати, если уж вспомнили Буча. У него в ООАиП я усматриваю сразу две прямые аналогии: 1. Диаграммы модулей (компонентов) 2. Диаграммы классов, в которых разрешено только отношение использования (допустимое ограничение, если мы хотим отразить лишь поверхностную статическую структуру системы). Отношение использования, если мне память не изменяет, Буч называет еще отношением "клиент-сервер".
	VVV 22 Mar 2002 10:25 AM
to bosm: Не могли бы Вы привести пример исользования вашей SOD. К примеру программу выводящую "Hello world".
	bosm 22 Mar 2002 1:22 PM
2VVV: С удовольствием! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //создаем компоненты new System:IO:Console console; new My:Cool:Component hw; //задаем их свойства hw.text = "Hello, World!"; //соединяем разъемы connect hw.output -> console.output; //и запускаем! run hw; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Парсер соответствующего языка уже готов: я написал его с помощью замечательной библиотеки Spirit (spirit.sourceforge.net). Ну и все остальное будет, надеюсь... :)
	eXOR - billygmicrosoft.com 22 Mar 2002 3:03 PM
2 bosm: Наконец - то и мне стало понятно о чем речь. ;-).
	MX 22 Mar 2002 8:04 PM
По-моему эти идеи давно используются: потоки с фильтрами, всякие data-bus-ы. Или я недопонял?
	RoN - rodionlenta.ru 23 Mar 2002 12:29 AM
:-/// My::Cool::Component hw; hw.text = "Hello, world !"; std::cout << hw.text; Чем это хуже ?
	glassy 23 Mar 2002 3:31 AM
или printf("Hello, world!"); :)
	bosm 23 Mar 2002 5:01 AM
Каков вопрос-таков ответ... :)) MX, Вы недопоняли. Потоки с фильтрами могут иметь только один интерфейс: файловый ввод-вывод, опосредованный pipe-ом. В моей модели видов интерфейсов может быть сколько угодно, и они СОВЕРШЕННО НЕОБЯЗАТЕЛЬНО предназначены для передачи данных. 2RoN: я оценил :)))
	RoN - rodionlenta.ru 23 Mar 2002 6:24 PM
У меня сейчас нету книжки Брукса под рукой, поэтому процитировать дословно это место не могу. Речь там шла о ненужности блок-схем при разработке и относилась ещё ко временам процедурных языков. Идея была в том, что рисование блок-схем - пустая трата времени, потому что исходник на языке высокого уровня и так достаточно ясно отражает логику программы. Мне кажется, что тоже самое можно было бы сказать и о ОО кейс-средствах. Почему, к примеру, надо считать, что такой текст: class Fucker { public: void FuckThis(); void FuckThat(); void FuckItAll(); }; менее понятен чем Бучевские UML-ные облака и прямоугольники? По-моему при использовании нормального ООЯП структура приложения должна быть нормально видна и из исходника. Если, конечно, приложение "прошаренно спроектировано" :)) А если через ж... - то тут уже никакой кейс не поможет, имхо.
	Qrot 25 Mar 2002 12:40 AM
2RoN: согласен полностью с последним постнгом. и с предпоследним твоим же тоже - разницы никакой. правда сейчас наверно какой-нить старпер придет и скажет что мы с тобой тут пионеры молодые необученные, ну да ничего :)) вобщем то, авторы UML сами предостерегали от серьезного отношения к своему детищу
	Tolik 25 Mar 2002 11:33 AM
2 bosm По-моему, тебе будет очень интересно почитать про Microsoft BizTalk Orchestration
	PTO - kruchkovkgb.ru 25 Mar 2002 2:54 PM
2 Tolik: не, оркестрейшн оно для распределенных вычислений хорошо... автор все локальную машину окомпонентить хочет.
	C# Man - semdiyahoo.com 25 Mar 2002 4:39 PM
2 bosm: ето как же по IUnknown из VBScript-а то?? тама тока диспачем.... 2ол: .НЕТ есчё очень далека от идеала... другими словами - нету там нормальной компонентной структуры для реального применения...наверно потому что над .НЕТ работали такие же теоретики как и автор... новая фиговина названая ObjectSpaces ещё тока разрабатывается.... 2 bosm: Буч кстати уже давно пошёл дальше ООП - а конкретно - patterns ... а Ваша теория действительно стара как мир (ну как минимум лет 10 :)... проблема ж в практическом осуществлении ентой идеи...
	C# Man - semdiyahoo.com 25 Mar 2002 4:41 PM
2PTO: вот на викенде напробывался Jameson ... так себе пойло (правда небыло там 12-летнего такшта ето непоказатель Ж)))
	PTO - kruchkovkgb.ru 25 Mar 2002 5:02 PM
2 C# Man: вот все говорят Карузо, Карузо, да не слуха не голоса, шепелявит и гнусавит... а где вы Карузо слышали - да тут Рабинович напел... 12 лет это очень важно... ну и обстановка и чем разбавлять и как смешивать... да и уж не с чивас рыгал сравнивать все же...
	C# Man - semdiyahoo.com 25 Mar 2002 5:10 PM
2РТО: обстановка + толстая COHIBA - ето обязательно... но вот смешивать - считаю баловством и растратой народного добра ... (ну льда ещё можна добавить)
	PTO - kruchkovkgb.ru 25 Mar 2002 5:43 PM
2 C# Man: не, смешивать обязательно, хотя-бы и с содовой (ну и лед ессесно), чистый вискарь пить пошло ИМХО... я предпочитаю с колой (я знаю что это тоже пошло и настоящие знатоки меня всякими словами назовут, но люблю я так), а недавно попробовал смешать с Байкалом от Черноголовки - обалденные ощущения... а Кахибу или Ромео и Джульетту это да... я тут привез 2 коробки чудесных сигар, которые делают только в Кантоне Тичино и там же только и продают - тоненькие, но длинные и с канальчиком внутри... вкус специфиский... идеально пошло с Арманьяком 1949 года... правда конца мероприятия уже не помню :)
	C# Man - semdiyahoo.com 25 Mar 2002 5:54 PM
2РТО: надеюсь что Арманьяк-то не смешиваете с колой :) к сожалению я есчё ненапрограмировался для "...Арманьяком 1949 года..." :) может лучше водку обсудим... :)
	me - userinternet.com 25 Mar 2002 6:19 PM
Велосипеды нынче в моде, я смотрю. >> По-моему при использовании нормального ООЯП структура приложения должна быть нормально видна и из исходника. Насколько я понял из Буча, диаграммки нужны не для лучшего понимания, а для того, чтобы _сначала_ продумать что и как сделать надо, а не в процессе. Типа, картинки человек лучше воспринимает, нежели буковки:)). В конце концов, УМЛ изобрели для "обезьян", а для "нормальных пацанов Страдивари делал барабаны" (с) из анекдота. ЗЫ: RoN, в том примере (class Fucker), я не понял только одно: кто кого трахать должен?:))))
	Qrot 25 Mar 2002 7:18 PM
2C# Man & PTO: армянский коньячок тож ничего, лет 15-ти... особенно если еще недопрограммировал до Арманьяка 49-го :) C# Man: из Irish еще Tullamore Dew протести - мне она больше чем Jameson нравится
	C# Man - semdiyahoo.com 25 Mar 2002 7:52 PM
Qrot: армянский это хорошо - тока сложно достать его в наших краях... Tullamore Dew - если найду - обязательто испробую...
	PTO - kruchkovkgb.ru 25 Mar 2002 8:18 PM
2 Qrot: насчет Дью поддерживаю... вкус гораздо мягче и можно даже не разбавлять :) 2 C# Man: Арманьяк конечно не разводим :) только если с кофе :) Бутылочка хорошая была - заказчик довольный выставил за успешно сданный проект... а вот водовку не люблю я, как и пиво :)
	C# Man - semdiyahoo.com 25 Mar 2002 8:53 PM
2РТО: конечно у водки вкусовые качества отсутсвуют :))... но пиво??!! пиво оно ж как вино... там такой букет...покачто лучше бельгийского пива ничего непивАл...
	PTO - kruchkovkgb.ru 25 Mar 2002 9:06 PM
2 C# Man: из того пива, что понравилось - темный Paulainer (но тока из бочки) и Hurlimann тож темный... все остальное _для_меня_ моча филина... о еще одно вспомнил - то что из чана разливают в пражской пивной "У Флеку"...
	C# Man - semdiyahoo.com 25 Mar 2002 9:33 PM
2РТО: по бочоковому я не експерт - так-как в америках пиво варят - так себе.... туточки линк на бельгийское: http://belgianstyle.com/mmguide/example/example.html многое пивал - так как товарищ один тут есть - бельгиец... возит... у них специфика - пиво крепкое (в среднем 8%, но есть и 15%!!!) - так как водки непъют....
	PTO - kruchkovkgb.ru 26 Mar 2002 11:27 AM
2 C# Man: ну в америках в пиве народ мало понимает, это я соглашусь... помню по-приколу в лас-вегасе заказали "Старопрамен"... принесли суки :) У вас там если и пить, то только гиннес какой-нить и то, только в айришпабе (надеюсь не в Юте живешь :))
	C# Man - semdiyahoo.com 26 Mar 2002 4:08 PM
2РТО: не ... на жаркой флориде ... из пива тут доступно Heiniken, Becks, Ginness + Canada beer + Australia beer. Budwiser SUUUUCKS! Есть есчё выбор Голандского неплохой.... а барам я тут недоверяю... накупят - "Beer Kits" и варят...я и сам так могу....
	yuraka - yurakayahoo.com 2 Apr 2002 3:11 PM
Любителям писать без UML-я: интерестно мне посмотреть на того, у кого в проекте более 200 классов да STL в придачу, да ATL. Разберетесь по сорсам? Гы...
	Просто прохожий 5 Apr 2002 1:55 PM
bosm, в общем ты правильно расписал. Твой первый уровень (библиотеки) это .Net Framework, II уровень - Assembly (пакеты для инсталляции над .Net), III уровень сейчас усиленно разрабатывается (люди учат С#). Так что ты прав. Только опоздал. Примерно на год.
	bosm 6 Apr 2002 5:27 PM
Ничего подобного. 1) .Net неприменим в области системного программирования 2) С# - язык для описания алгоритмов, а не схем. (Хотя сочетание нескольких признаков C# позволяет двигаться в этом направлении, но зачем использовать для этого алгоритмический язык?) Но! Я согласен, что все движется именно в этом направлении. :)) Просто нужно довести дело до логически полного воплощения. Так что кто опоздал - это мы еще _внимательно_ посмотрим.
	Просто прохожий 6 Apr 2002 9:29 PM
1. При чем тут системное програмирование? Нет в твоей статье упоминания такого программирования. Но если уж пошла речь то и .NET Framework, и твой первый уровень густо замешаны именно на _системном_ программировании. Так как усиленно-платформозависимы. 2. Странный ты - причем тут C#? Это я к слову. Усиленно рекомендую почитать про assemblies (установка - от C# не зависят). В частности их манифест содержит твои "разьемы". И много кой-чего другого интересного. Ты опоздал. И дело прошло дальше _логического_ воплощения - к практическому. Угроханы миллиарды, написаны новые языки, продается новая ИДЕ а в Интернете, разворочена целая инфраструктура (слышал - веб-сервисы, сервера аутентификации итд.). На это было нужно время. Несколько лет.
	Просто прохожий 6 Apr 2002 9:57 PM
Млин. Перечитал и понял что непонятно. Ты хотел сказать что твоя технология имеет целью системное прграммирование? Ни фига подобного. Цель: "Уровень 3.Системы. Соответствует низкому уровню подготовки программиста (сборщика), вплоть до ее отсутствия. Знание методов и концепций программирования здесь не нужно, достаточно прочитать документацию на доступные детали (компоненты).". А теперь перечитай определение системного программирования. "Разъемы" у assembly в твоем значении (кстати очень узком) - это экспортируемые типы и ресурсы. Если шире - это совокупность ее метаданных. Возьми в качестве легкого чтива этот линк http://www.gotdotnet.ru/classify.asp?c_no=4 . После этого сможем поговорить _по существу_.
	bosm 7 Apr 2002 6:57 AM
Подумай над следующим примером: инженер (в широком смысле слова) имеет дело с очень сложной операционной системой, которая работает на таком железе, под которое ни MS и ни один .нетовец никогда писать не будет. Хотя кто-то, м.б., думает, что все программирование на свете - это написание баз данных, веб-страниц и image-viewer-ов, и все это под виндами. Мой подход прост, я оцениваю его в несколько (десятков) тысяч строк, а на lisp-е и того меньше. Он применим и в системной области (для создания и настройки ОС), и в обычном оффисном программировании. Он более обобщенный, в нем отсутствует все лишнее. Создателю схемы не предоставляется возможности писать программы вообще - он может только лишь создать схему, и создать ее по ясным, четким, интуитивно-ясным законам совместимости. Ссылки почитаю, спасибо.
	bosm 7 Apr 2002 10:44 AM
Да, забыл: я не имел в виду, что моя "технология имеет целью системное программирование". Но она может применяться и там. Нужно лишь немного фантазии. А .Net не может - и именно потому, что "угроханы миллиарды, написаны новые языки, продается новая ИДЕ а в Интернете, разворочена целая инфраструктура". Все это из другой оперы, хотя многое похоже. Уровень 3 не противоречит определению системного программирования :)). Заметь, я нигде не говорил, что все компоненты _обязаны_ заключаться в executable файлах, как в .Net. В системном случае они могут помещаться в объектных файлах, тогда пользователю нужна будет среда линковки (хотя он может об этом не знать). Но система по прежнему будет представлена в виде понятной, прозрачной схемы.
	Просто прохожий 7 Apr 2002 4:14 PM
В первом посте ты сказал что считаешь что метод применим для создания ОС. Во втором упомянул что собираешся строить из обьектных файлов (да хоть из сырцов). Ты Линукс имел в виду? Этим _уже_ занимаются десятки компаний (лет 10 эдак). Так что вернемся к нашим баранам. В чем же новизна-то? Пжлста, хоть один пример где есть новость (учти - чтоб не был похож на уже _давно_ существующие и раскрученные J2EE, .Net, Linux, Delphi, COM). Если таких примеров не будет а пойдет теоретизирование, будем считать что как минимум заголовок статьи неудачен. Я бы назвал это обобщенным описанием компонентной технологии, теоретически описанной в шестидесятых и практически реализованой в начале девяностых. Этот этап прошел. Сейчас возникли новые задачи о которых ты еще не подумал... (Кстати, насчет фантазии. Почитай все-таки про .Net и подумай о следующем этапе. То что там не будет системного программирования чересчур смелое утверждение).
	bosm 7 Apr 2002 5:11 PM
> компонентной технологии, теоретически > описанной в шестидесятых и практически > реализованой в начале девяностых Мое глубокое убеждение состоит в том, что если бы это _действительно_ произошло, то 1. Люди (хорошие, полезные люди), ни с какой стороны не являющиеся программистами, не называли бы себя так только лишь потому, что они умеют ваять нечто на VB. Они вообще не пользовались бы алгоритмическими языками, а составляли бы СТАТИЧЕСКИЕ СХЕМЫ, безопасные, не требующие отладки, не приводящие к накладным расходам в runtime. Тем самым энергия этих людей была бы использована в мирных целях. 2. Были бы разработаны стандартные классы интерфейсов, покрывающие 80-90% нужд описания взаимодействия между компонентами в различных задачах. Сейчас я знаю только один такой интерфейс, проверенный временем - перенаправление ввода-вывода :). 3. Тот-же Линукс (непонятно почему появившийся в предыдущем посте) был бы изначально представлен в виде ясной архитектурной схемы, которую можно было бы просматривать и - даже - видоизменять графически. И не только Линукс. 4. Хорошим тоном для среды разработки УЖЕ ТОГДА стала бы тесная интеграция со средствами распространения. Однако это только начинает происходить сейчас (например, в .Net). 5. Я бы мог заменить менеджер памяти Win95/98, купив его у стороннего производителя (фантастика? - нет, прагматический подход). И т.д. и т.п. На все остальное не отвечаю, т.к. отвечал уже неоднократно.
	Просто прохожий 7 Apr 2002 9:46 PM
Похоже на начало одной из "бесконечных" дискуссий. Так что постараюсь быть как можно более точным и _кратким_ 1. Ты сам себя опровергаешь. Не имеет значения как зовут этих людей. Если дошло до того что "люди называют себя программистами только лишь потому, что они умеют ваять нечто на VB" так может это и есть обещанное тобой счастье? VB и Delphi (кстати) можно прекрасно использовать только в целях тобой перечисленных. Мешают недостаточное число компонент (у тебя их число должно исчисляться миллионами) и то что эти языки можно использовать и в более универсальных целях. (VB прост но это не дает тебе право рассматривать его свысока - сложность программ определяется не используемым языком программирования, а предметной областью). 2. Ты просто показываешь свою неосведомленость. Читать Вирта, паттерны дизайна, STL, SQL, XML, заходить на w3.org, вообще про стандарты, ANSI... Идея стандартных интерфейсов для всех _давно_ используется в целях конкурентной борьбы (прикинь ;)). 3. У тебя есть идея о том что ОС Линукс поставляется в виде исходников и его можно пересобирать, затачивая под свою задачу? (есть даже специальные стандартные тулзы (графические тоже) которые позволяют выбирать что ты хочешь включить в ядро - эти тулзы будут относиться к твоему 3 уровню. Угадай что находиться на 1-ом и 2-ом?) 4. Читаешь про assemblies и .rpm и узнаешь что эта идея _тоже_ не нова. Ты угадал - так и делается. ;) 5. Ну ты и загнул. Ты хоть представляешь о продукте какой степени сложности и интегрированности говоришь? Хорошо, предположим разработали к нему интерфейс (несколько сот тысяч "разьемов"), опубликовали его. Кто-то сделал подходящий t-компонент. Представил я себе реализацию "подключения" этого компонента... Прокси, визиторы итд... ОС которую ты получишь в данном конкретном случае будет в сотни раз медленее. А конкуренцию никто не отменял пока что. Так что другой калькулятор - нет проблем. А менеджер памяти - извини подвинься. Кстати. Я просил конкретный практический пример новизны твоего взгляда (без пересказывания существующих технологий). Для этого почитай осногы кой-чего чтоб не выдать за свое. Опять.
	bosm 8 Apr 2002 2:41 AM
> 1. Ты сам себя опровергаешь. Утверждение не доказано в предыдущем посте. > VB и Delphi (кстати) можно прекрасно использовать > только в целях тобой перечисленных. Мешают недостаточное > число компонент (у тебя их число должно исчисляться > миллионами) Можно использовать для _программирования_ _похожим_ (по описанию) способом. Я же предлагаю РАСПРОСТРАНЕНИЕ в виде схемы - причем такой схемы, которую пользователь сможет изменять. Миллионы компонент не понадобятся - это неправильное понимание предлагаемой технологии. Смысл следующий: схема статического проектирования (которая в любом случае _всегда_ существует) оставляется видимой пользователю. Т.е. компоненты могут быть любыми, разработанными под конкретные нужды самим авторами программы (хотя, конечно, могут быть использованы и сторонние компоненты). > VB прост но это не дает тебе право рассматривать его свысока Никогда не рассматривал VB свысока. Но считаю, что инструменты его класса следовало бы упростить (и предлагаю направление такого упрощения) > Ты просто показываешь свою неосведомленость. Да неужели? Цитирую возражение мне, поступившее от ОЧЕНЬ осведомленного человека, автора известного ресурса по С++ Игоря Ткачева: > Разъёмы, понимаишь, делают одни, а использут другие. > Первые делают ширпотреб, а вторым нужен индпошив. Вторые > просят первых вот здесь подлатаь, а третьим начинает жать, > на четвёртых висеть, пятые посылают всех и идут искать других > первых или клепать всё сами. Вот такие разъёмы получаются, > интерфейсы так сказать Так что, по мнению специалистов то, что я предлагаю, неосуществимо по прямо противоположной причине: стандартные интерфейсы, покрывающие все или почти все нужды взаимодействия статических компонентов, по их мнению, просто _невозможно_ разработать. > Читать Вирта, паттерны дизайна, STL, SQL, XML, заходить > на w3.org, вообще про стандарты, ANSI Опять перечислены "похожести". По моему, fuzzy logic на этом форуме становится болезнью. А с каким гонором, просто удивительно... > Читаешь про assemblies и .rpm и узнаешь что эта идея _тоже_ > не нова. А я что, говорил что она нова? По-моему, я сказал лишь, что это до сих пор не стало хорошим тоном.... В общем, опять fuzzy logic. > интерфейс (несколько сот тысяч "разьемов") ??? В моей терминологии "разъем" и "интерфейс" - почти одно и то-же, почитай статью. Это во-первых. Во-вторых, если ты имеешь в виду "несколько сот тысяч функций", то глубоко заблуждаешься. Функций должно быть немного. Ты таким поучительным тоном отсылаешь меня к различным источникам, которые я читал в детстве, поэтому позволь послать и тебя: поизучай ядра операционок с открытым кодом. Начни с Xinu, хорошая учебная ОС, всего 4000 строк. Потом перейди к ранним версиям Linux'а. > Представил я себе реализацию "подключения" этого > компонента... Прокси, визиторы итд... ОС которую ты > получишь в данном конкретном случае будет в сотни раз > медленее. Какие прокси, какие визиторы, почему медленнее? Я говорю о статической линковке, почитай предыдущие посты... > (без пересказывания существующих технологий). Для этого > почитай осногы кой-чего чтоб не выдать за свое. Прошу Вас привести мне пример неизвестной мне технологии, в которой приложение поставляется пользователям в виде статической схемы, причем так, что пользователь может просматривать и видоизменять эту схему, настраивать ее, покупать компоненты у сторонних производителей и прочее, и прочее. Прошу Вас привести мне пример хотя-бы одной среды разработки, которая поддерживала бы создание таких программ.... Спасибо...
	bosm 8 Apr 2002 4:42 AM
Да, забыл: > 3. У тебя есть идея о том что ОС Линукс > поставляется в виде исходников и его можно > пересобирать, затачивая под свою задачу? Нет у меня такой идеи. Цитирую себя же: "Тот-же Линукс ... был бы изначально представлен в виде ясной архитектурной схемы". Отсутствие такой схемы (не в голове или в виде кода на С, а в виде специализированного представления) на данный момент - не просто факт, а неприятная для многих реальность. И уж это точно не моя идея. Почитай конфы по Linux.
	Просто прохожий 8 Apr 2002 12:26 PM
По-моему ты просто всех считаешь дураками... Может оно и вправду так? ;) Мне просто интересно почему ты подумал что я не знаю что у тебя набор разъемов и интерфейс одно и то же? Почему думаешь что я думаю что интерфейс это функции? Нет я как раз думаю что ваш интерфейс на менеджер памяти, заменяющий майкрософтовский, грубо будет включать несколько тысяч требований спецификации, которые выльются в сотню тысяч разъемов. Теперь по другому поводу... Надо внимательно читать. Пример. Пишешь "2. Были бы разработаны стандартные классы интерфейсов, покрывающие 80-90% нужд описания взаимодействия между компонентами в различных задачах. Сейчас я знаю только один такой интерфейс, проверенный временем - перенаправление ввода-вывода :). " в контексте степени развития компонентных технологий. Пишу "2. Ты просто показываешь свою неосведомленость. Читать Вирта, паттерны дизайна, STL, SQL, XML, заходить на w3.org, вообще про стандарты, ANSI... Идея стандартных интерфейсов для всех _давно_ используется в целях конкурентной борьбы (прикинь ;)). " От тебя читаю (с удивлением) "Опять перечислены "похожести". По моему, fuzzy logic на этом форуме становится болезнью. А с каким гонором, просто удивительно..." Бог с тобой. Я не говорил про твой "новый" взгляд на компонентные технологии. Я перечислил (будь внимателен) ИНТЕРФЕЙСЫ, ПРОВЕРЕННЫЕ ВРЕМЕНЕМ. Извини но если перенаправление ввода-вывода является интерфейсом, тогда стандарты ANSI и www.w3.org, HTML, SVG, http, zip, rtf, XML, hierarhic file system это просто аксиомы. Без знания некоторых невозможно выживание тебя как пользователя (о программерах я молчу). "Прошу Вас привести мне пример неизвестной мне технологии, в которой приложение поставляется пользователям в виде статической схемы, ..." Стоп. Когда объяснишь что такое "статическaя схемa" в твоем понимании. А то опять начнешь юлить. Кстати, моего вопроса о конкретном практическом примере доказывающем новизну твоего взгляда это совсем не снимает. Так что будь так добр, бери и опиши. Остальное к делу не относиться - заблуждайся на здоровье. Пример давай.
	bosm 8 Apr 2002 1:19 PM
> По-моему ты просто всех считаешь дураками... Ни в коем случае. > Может оно и вправду так? ;) Скорее всего, нет. > почему ты подумал что я не знаю что у тебя набор > разъемов и интерфейс одно и то же? Исходя из твоей фразы <<интерфейс (несколько сот тысяч "разьемов")>>. Я понял, что ты имел в виду другое значение слова "интерфейс", поэтому можешь не объяснять. > Надо внимательно читать. Надо внимательно писать. В таком случае я объясню тебе в свою очередь что _я_ имел в виду: я не знаю другого интерфейса, проверенного временем, который используется повсеместно для показа структуры работающей системы пользователю (в виде скриптов sh), которую он к тому-же может в любой момент изменить, кроме интерфейса перенаправления ввода-вывода. Есть еще экзотические интерфейсы, применяемые для различных задач вроде построения и эмуляции физических схем, но они к делу не относятся. Поскольку все обсуждение ведется (я надеюсь) в русле этой идеи, это нужно бы держать в голове, а? Спасибо за свежие новости о существовании кучи стандартных интерфейсов, я оценил. > ANSI ... HTML, SVG, http, zip, rtf, XML, > hierarhic file system Ты, как я погляжу, соревнуешься сам с собой в том, чтобы перечислить как можно больше стандартов в рандомизированном порядке. Это кто всех дураками-то считает? > думаю что ваш интерфейс на менеджер памяти, заменяющий > майкрософтовский, грубо будет включать несколько тысяч > требований спецификации, которые выльются в сотню тысяч > разъемов Это, мягко говоря, неверная оценка. Читать (как ты выражаешься) что-нть про ядро Linux - просто для того, чтобы среднее количество функций, существующих в средней операционке, имелось в голове - плюс к куче других полезных сведений, которые там уже есть. > Когда объяснишь что такое "статическaя схемa" в твоем > понимании. А то опять начнешь юлить. Статическое разбиение программы - это такое разбиение ее на компоненты, при котором все компоненты создаются и инициализируются в начале ее работы, и уничтожаются (возможно, сохранив свое состояние) в конце ее работы. Соответственно, статическая схема - это схема соединения разъемов статических компонентов. > Остальное к делу не относиться - заблуждайся на здоровье. Остальное к делу не относится, но я бы не хотел, чтобы ты заблуждался, хотя помешать этому не могу.
	Просто прохожий 8 Apr 2002 3:59 PM
Итак, имеем > "Статическое разбиение программы - это такое разбиение ее на компоненты, при котором все компоненты создаются и инициализируются в начале ее работы, и уничтожаются (возможно, сохранив свое состояние) в конце ее работы. Соответственно, статическая схема - это схема соединения разъемов статических компонентов. и > Прошу Вас привести мне пример неизвестной мне технологии, в которой приложение поставляется пользователям в виде статической схемы, причем так, что пользователь может просматривать и видоизменять эту схему, настраивать ее, покупать компоненты у сторонних производителей и прочее, и прочее. Прошу Вас привести мне пример хотя-бы одной среды разработки, которая поддерживала бы создание таких программ...." Определения не до конца понятны (начало работы чего? что является компонентой в этой схеме? ...) но рискну предложить хорошо распростненый пример - 1С ?
	bosm 8 Apr 2002 4:17 PM
:)) Знаком, знаком. Но, пожалуй, "1С - технология" - это сказано очень сильно. "Операционая система, построенная на технологии 1С" - как звучит, а? Или так: "Web-сервер, построенный на технологии 1С" - тоже очень хорошо. Просто сказочно. Ну так что, еще примерчик? Ну пожалуйста... > начало работы чего? В определении сказано "ее работы", т.е. программы > что является компонентой в этой схеме? Интуитивное понимание термина "компонента", как логической части программной системы. "Модуль" в терминологии ООАиП Буча.
	miroh - plasmonmail.ru 9 Apr 2002 11:58 AM
Грустно девушки.... 1С - технология ... Может просто получше ознакомиться с компонентным подходом J2EE и Net. Дело все в том, что вся компонентная индустрия пошла гораздо дальше всех этих невнятных сентенций. Какието статические схемы - это что за шестидесятничество? Компоненты давно уже динамические и динамически заменяемые, да еще и распределенные. В общем 1С- ну 1С так 1С....
	bosm 9 Apr 2002 12:29 PM
> Может просто получше ознакомиться с компонентным > подходом J2EE и Net. На этой же странице ниже находятся подобные предложения, потрудитесь перечитать. Сравнения с J2EE и .Net за месяц, прошедший с опубликования статьи, я получал неоднократно. В основном пишущие (как и Вы) замечают похожести, причем каждый в меру своего знакомства с предметом. Пока никто не смог доказать, что .Net содержит то в полном объеме, что я предлагаю, потому как объемы .Net и моей технологии пересекаются в очень небольшой степени. Компонентная индустрия пошла действительно очень далеко. Но немного в другом направлении. В частности, мало попыток распространить компонентный подход (в широком смысле слова) на системное программирование (хотя попытки есть). Мало работ по представлению структуры работающей системы для пользователя. Я предлагаю и то и другое в удобной и безопасной форме. Как называть (статические схемы или иначе) - вопрос вкуса. Я в курсе, что многие хорошо воспринимают только те названия, которые придуманы MS.
	Просто прохожий 9 Apr 2002 2:24 PM
miroh, про J2EE&.Net я уже пытался. Не помогает. bosm, "Операционая система, построенная на технологии bosm" звучит не лучше. Так что по существу-то? Я уверен что он точно описывает _твои_ требования. Давно пора _тебе_ свои примеры привести. Или все-таки новизны нет?
	bosm 9 Apr 2002 2:47 PM
Прохожий, если .Net точно описывает мои требования (т.е. применим на всех уровнях программирования, прост и предоставляет пользователю безопасный способ изменения структуры приложения в широких пределах), то ЗАЧЕМ ты сказал "1С", над чем miroh совершенно резонно посмеялся? Где _твой_ пример? Опять .Net, с которого мы начали разговор? Хорошо, давай поговорим о .Net снова. Только, так как здесь я защищаю свои идеи - докажи _ты_ мне, что эта технология удовлетворяет перечисленным мною здесь и ранее требованиям. Про сборки можешь на повторять - я скачивал .Net среду разработки еще в первых доступных бета-версиях. Я даже не упомянул .Net в статье - именно потому, что я предлагаю теоретически и практически простую, фундаментальную систему, а не коммерческое средство поддержки сервисов (хотя и, несомненно, компонентное средство - было бы удивительно, если бы случилось иначе).
	Просто прохожий 9 Apr 2002 7:08 PM
Про .Net я тебе уже доказывал. Посмотри еще раз - на твои три слова о своей "технологии" я тебе описал что будет на каждом из уровней. Не намерен больше ввязываться в эту муть... Ты опять поставишь условие - типа нет, должна быть "статическая схема" со "статической линковкой" чтоб был не J2ЕЕ и не .Net потому что у них не только это есть а еще куча другого и чтоб не 1С потому что смеются! Хочешь чтоб я тебе нашел? Нема дурных. Ищи сам. И повторяю - 1С прекрасно подходит под твои определения. Если смеются - что-ж такова цена твоего творения. > "Статическое разбиение программы - это такое разбиение ее на компоненты, при котором все компоненты создаются и инициализируются в начале ее работы, и уничтожаются (возможно, сохранив свое состояние) в конце ее работы. Соответственно, статическая схема - это схема соединения разъемов статических компонентов." этими компонентами в 1С являются - конфигурации (они бывают разными, инициализируются, уничтожаются (выгружаются из памяти), сохраняют свое состояние в БД и даже больше того - они сами манипулируемы другими компонентами) - модули 1С. То есть имеется ядро к которому затем можно добавить модули несущие дополнительные функции (SQL-доступ, публикацию в вебе, распределение БД). Они манипулируют другими компонентами. Заметь все они статичны, то есть разработаны ДО использования. > Прошу Вас привести мне пример неизвестной мне технологии, в которой приложение поставляется пользователям в виде статической схемы, причем так, что пользователь может просматривать и видоизменять эту схему, По схеме 1С Франчайзинга существует множество предприятий которые перепродают конфигурации после внесения своих изменений, пользователь может установить или нет какие-либо компоненты, видоизменять конфигурации итд. > настраивать ее, покупать компоненты у сторонних производителей и прочее, и прочее. Прошу Вас привести мне пример хотя-бы одной 1С Франчайзинг. Есть в 1С и настройки всего на свете (включая распредел. БД) > среды разработки, которая поддерживала бы создание таких программ...." Как ты угадал ?! Действительно ЕСТЬ среда разработки для этих программ и даже изменения самого себя. (как и в .Net) ;)
	bosm 10 Apr 2002 3:09 AM
> Не намерен больше ввязываться в эту муть... А ты и не связывался. Так, указал похожие черты. Кстати, "муть" - это то, что не вполне хорошо понимаешь. Разделяемые (совместно используемые) сборки действительно похожи на t-компоненты, но только похожи, причем отдаленно. Я это могу доказать на примерах, но что-то никто не спрашивает. 1С, понимаешь... > Ты опять поставишь условие - типа нет, должна > быть "статическая схема" со "статической линковкой" Ну статическая линковка обязательна только в системных проектах. В общем случае оба вида линковки допустимы. > 1С прекрасно подходит под твои определения. Да неужели? Вот это да... Ну что-ж, м.б. мы скоро увидим браузер, сделанный в 1С. Ах, да, забыл, он уже есть... IE называется - его вполне можно встроить в 1С, и не слишком сложно. ОК, прохожий, если ты считаешь 1С компонентной технологией, то спор с тобой, пожалуй, становится бессмысленным. А уж тем более если ты сравниваешь конфигурации 1С с компонентами. Bye.
	miroh - plasmonmail.ru 10 Apr 2002 9:50 AM
2bosm Я не про похожести,а про различия. Современный компонентный подход - это позднее динамическое связывание, поиск, активация, использование компонентов. Причем еще в распеделенных вычислительных системах,причем еще транзакции и сохранение состояний и еще много(уже больше технических деталей). Вы же предлагаете опять что то вроде dll. -Дак на таких библиотеках -компонентах весь Виндюк стоит. Причем и заменять их можно и удалять. Фактически процедура инсталляции и есть ваш интерфейс сборщика. COM уже дальше вас пошла. В JavaBeans даже есть специальные сборщики компонентов, где любой среднеквалифицированный пользователь может не только установить компонент, но и сконфигурировать его как надо. VS4+ позволяет так же работать с ActiveX. Для J2EE NET простых сборщиков пока нет - пока.
	bosm 10 Apr 2002 10:43 AM
Замечательно! Наконец-то! И я об этих различиях! Совершенно верно, технологическая задача создания\использования\связывания компонентов (в динамическом смысле), а так же организации распределенных вычислений мною не ставится вообще. Большинство из этих вопросов довольно изящно решены уже в стандарте CORBA. Все это вполне может работать поверх моей схемы и меня не интересует. Вы замечательно сформулировали различия. Основная тематика этой работы (а я ее продолжаю) - представление программной системы (т.е. как набора компонентов, так и работающей программы) для продвинутого пользователя (администратора, интегратора, инженера т.д.). Гибкое, легко изменяемое и при этом устойчивое, безопасное представление, сравнимое по гибкости с системой утилит UNIX, только в компонентной области. COM решает эти вопросы неудовлетворительно, а вернее вообще не решает. Платформа .Net ближе к делу, но сложна, плохо переносима, пока несовместима с некоторыми стандартами программирования, в которых ведется весомая часть разработок для промышленности. Я предлагаю очень легковесное решение, которое НЕ отрицает использования существующих технологий и не пересекается с ними. Miroh, я хочу Вас совершенно искренне поблагодарить. Обсуждаемая статья, конечно, очень несовершенна, поскольку вызывает подобное недопонимание. Я долго думал о том, как исключить такие сравнения. Сейчас, благодаря Вашему посту, все сложилось в приемлемую схему. Спасибо.
	Просто прохожий 10 Apr 2002 11:54 PM
Не существует обшепризнаного определения компонент. Зато 1С прекрасно вписываются в ваши "cтатические схемы". А чего обижаетесь на 1С? ;) Крутые технологии подавай? > Платформа .Net ближе к делу, но сложна, плохо переносима, пока > несовместима с некоторыми стандартами программирования, в > которых ведется весомая часть разработок для промышленности. Я настаиваю на том что она не просто "ближе к делу" но является надмножеством Вашей схемы._Практическая_ реализация Вашей схемы будет тоже сложной. Насчет плохой переносимости поговорим через годик. С какими стандартами программирования это она несовместима? Я рад что у Вас наконец "все сложилось в приемлемую схему" :). Если бы это случилось до опубликования статьи то все было бы просто замечательно. Для пущей верности уберите эпитет "новый".
	bosm 11 Apr 2002 4:28 AM
Я не обижаюсь. Просто не является 1С компонентной технологией. Наверное, это хорошая система для своих задач, но не более. Это во-первых. Во-вторых, если уж Вы воспользовались словом "надмножество", то могу сказать Вам, что предлагаемая мною схема может быть задана в виде простой алгебры, состоящей из 1. Классов с отношением частичного упорядочения, называемым "наследование" 2. Разъемов, для которых определен предикат "принадлежности к классу" и введено отношение "совместимости", которое зависит от наследования классов так, как описано в статье. 3. Компонентов, каждый из которых представляет собой множество "левых" и "правых" (по отношению к совместимости) разъемов. При этом схемой является множество компонентов с булевой функцией соединения разъемов. В корректной схеме разъемы соединены в соответствии с отношением совместимости. Теперь вы можете попытаться строго доказать, что а. .Net является надмножеством предлагаемой алгебры б. 1С содержит подмножество, эквивалентное предлагаемой алгебре в. COM, CORBA, JavaBeans и т.п. делают операции с объектами этой алгебры доступными для пользователя (это не Ваше, но распространенное возражение). Заранее спасибо.
	bosm 11 Apr 2002 4:40 AM
Sorry, пункт а. некорректен - надмножеством этой алгебры может быть почти что угодно, хоть ассемблер. В общем-то, рассуждения о надмножестве - это "нечеткая логика", поскольку пока в системе не может быть явно выделено эквивалентное подмножество, затраты на его создание (например, в составе .Net) могут быть сколь угодно большими. Так что уж доказывайте пункт б. и по отношению к .Net. Удачи.
	bosm 11 Apr 2002 9:34 AM
Т.е. пункт б. тоже нужно читать "1С явно содержит эквивалентное подмножество" (в том смысле, что никакого дополнительного кодирования не нужно).
	Просто прохожий 11 Apr 2002 12:08 PM
> может быть задана в виде простой алгебры, состоящей из... Ага - вот и _настоящая_ идея проклюнулась. Об этом и надо было писать. Красоту оценил. ИМХО - она не в том месте используется. И это может все сгубить. Попробуйте применить ее для создания новой алгебры для обьектно-ориентированных БД (аналогу реляционной алгебры для реляционных БД). Будьте внимательны - теоретическая модель может иметь большую размерность. _Именно_ такой подход я рассматривал лет семь назад (есть публикации но не на русском) применительно к распределенным БД. Но набрел на лучший подход (который допускает на втором этапе снижение размерности за счет использования классификации - вот вам и нейронные сети и нечеткая логика ;) ). Смотреть здесь http://sirboris2000.boom.ru/thesis.html . Во второй главе найдешь что-то типа описанной тобой схемы, но для случая распределенных БД. Можешь использовать по аналогии матаппарат (глава 3 и 4 - чуствую точно пригодиться для твоей алгебры). Может что и пригодится ;). ЗЫ. К делу не относиться но в науке все фриварно. Видимо поэтому для меня этот жизненый этап так быстро закончился.
	Просто прохожий 11 Apr 2002 12:10 PM
Когда закончишь свою алгебру дай взглянуть. Жуть интересно. Покритикую с пеной у рта ;)
	bosm 12 Apr 2002 4:38 AM
не буду спорить, прохожий, позволю себе только указать на некоторые соответствия между статьей и определением, данным мною ранее. Итак, участок > предлагаемая мною схема может быть задана в виде простой > алгебры, состоящей из > 1. Классов с отношением частичного упорядочения, > называемым "наследование" соответствует следующему тексту статьи: > Роль разъема может взять на себя интерфейс, т.е. абстрактный > виртуальный класс, причем информация об иерархии наследования > для интерфейсов может быть занесена ... В этом тексте, конечно (как обычно в программистской литературе, если это не приводит к недоразумениям) смешиваются понятия "класс" и "экземпляр класса". Тем не менее, соответствие вполне однозначное. Далее, > 2. Разъемов, для которых определен предикат "принадлежности > к классу" и введено отношение "совместимости", которое зависит > от наследования классов так, как описано в статье. соответствует участку > Назовем такие «пустые места», т.е. требуемые интерфейсы, > клиентскими разъемами. Если компонент предоставляет > какие-либо интерфейсы для внешнего использования, они > могут быть названы серверными разъемами. Так сами собой > появляются правила соединения разъемов Следующий пункт > 3. Компонентов, каждый из которых представляет собой > множество "левых" и "правых" (по отношению к совместимости) > разъемов. соответствует тексту: > Пусть для каждого компонента указано, клиентом каких > интерфейсов он может (или должен) являться. (при этом подразумевается самоочевидным, что для каждого компонента указаны серверные разъемы, как обычно) Наконец, последнее замечание > При этом схемой является множество компонентов с булевой > функцией соединения разъемов. В корректной схеме разъемы > соединены в соответствии с отношением совместимости. соответствует тексту статьи: > пользователь сможет собирать или совершенствовать > программные системы, не прибегая к программированию, > а лишь добавляя необходимые компоненты и соединяя между > собой их совместимые разъемы.
	bosm 12 Apr 2002 4:44 AM
Вдогонку: тем не менее, я считаю статью недостаточно качественной. Но не потому, что идея там не раскрыта. Просто она раскрыта не очень подробно и в составе текста, приводящего к недоразумениям.
	0goH05oKaU - 9Bu5kzeue1Uy.com 15 Sep 2006 7:22 AM
M85HQJUvUoQT iwUcV1j3ZSb UXKXMJOhXv
	ztoYCkyfk2 - z3yZYXVTUpen.com 15 Sep 2006 7:23 AM
l6OOKiDus2jU o1myyeCBCWEg xVPJZKnZWfJ
	8X4sqib0sK - RAHGiqKVrhed.com 15 Sep 2006 7:23 AM
ehnfOKeImV 9vc1w3qx5TTk rCW1gNUDHVdZQx
	ILC9PVFbo5 - mixMLFw1OtXy.com 15 Sep 2006 7:24 AM
pycIAKzzww O39L9kZhi3 4FAloiIg33fV
	XjlGdW5OL7 - rKzCyMOgqNeQ.com 15 Sep 2006 7:24 AM
jz9gIUpNlGw TNDWSNdiPkr Nf0TIqkizye
	cduVotFScu - C8Vo5Vm3w5O9.com 15 Sep 2006 7:25 AM
YBRrVQiMtY9WU YuqcQZq3J1 e5dFicg9fp4i