Здравствуйте Aquila, Вы писали:
A>...то это, во-первых, для многих достаточно важное приложение, в отличии от фреймворка
Вот тут то собачка и порылась. Как только людям нужно будет приложение на нэте сделаное, то тут же и скачают. Так что главное чтобы твое приложение было людям нужно.
A>во-вторых, качают далеко не все (зачем?),
Статистика показывает что большинство перешло на 6-й эксплорер. А он ни в одну ОСь не ваходит.
A>а в-третьих — далеко не каждый пользователь может произвести такую сложную операцию, как скачку многомега и ее последующую установку. Да и зачем? Все программы, которые нужны, работают и безо всякого фреймворка, а если они требуют какие-то длл, то значит они просто кривые... Так рассуждают многие... Нет, это серьезная проблема для массовых программ.
Ну в общем ты сам к моим выводам пришел. Главное чтобы программа была нужна, а фрймворк дело десятое. 20 мег можно и по модему скачать.
Возми тот же янус. Тебе придется скачать 20 мег + 1. Но зато потом проблемы с просмотром в офлайне того же рсдн-а не будет. Думаю что оно того стоит. Тем более что пользователь Януса сам программист и фреймворк у него скорее всего уже есть. Ну а пользователи пользователя возмут фреймоврк у пользователя.
Здравствуйте, VladD2, Вы писали:
A>>...то это, во-первых, для многих достаточно важное приложение, в отличии от фреймворка VD>Вот тут то собачка и порылась. Как только людям нужно будет приложение на нэте сделаное, то тут же и скачают. Так что главное чтобы твое приложение было людям нужно.
Проблема в том, что они могут предпочесть менее гмм.. требовательное решение.
A>>во-вторых, качают далеко не все (зачем?), VD>Статистика показывает что большинство перешло на 6-й эксплорер. А он ни в одну ОСь не ваходит.
Что за статистика такая? Мои шпионы говорят, что это не так .
A>>а в-третьих — далеко не каждый пользователь может произвести такую сложную операцию, как скачку многомега и ее последующую установку. Да и зачем? Все программы, которые нужны, работают и безо всякого фреймворка, а если они требуют какие-то длл, то значит они просто кривые... Так рассуждают многие... Нет, это серьезная проблема для массовых программ.
VD>Ну в общем ты сам к моим выводам пришел. Главное чтобы программа была нужна, а фрймворк дело десятое. 20 мег можно и по модему скачать.
Нет. Программа должна установиться и работать. Если она не работает, то ее снесут и поставят другую .
VD>Возми тот же янус. Тебе придется скачать 20 мег + 1. Но зато потом проблемы с просмотром в офлайне того же рсдн-а не будет. Думаю что оно того стоит.
Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой. Если говорить в общем — это изрядно сократит количество пользователей этой, вполне возможно, замечательной во всех других отношениях программы. Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения. Мне не понравилось и пришлось снести все это. К тому же .NET-приложения мне показались медленными и прожорливыми. Смена операционной системы неприемлима .
VD>Тем более что пользователь Януса сам программист и фреймворк у него скорее всего уже есть.
Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится.
Здравствуйте Aquila, Вы писали:
A>Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой. Если говорить в общем — это изрядно сократит количество пользователей этой, вполне возможно, замечательной во всех других отношениях программы. Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения. Мне не понравилось и пришлось снести все это. К тому же .NET-приложения мне показались медленными и прожорливыми. Смена операционной системы неприемлима .
Первый запускающийся и что то делающий вариант я накидал за 4 дня. На С++ я бы ковырялся недели две. А до теперешнего состояния он бы скорее всего не дожил. Да и потом, на выбор платформы повлияло не только то сколько народу им пользоваться будет.
Здравствуйте Aquila, Вы писали:
A>Проблема в том, что они могут предпочесть менее гмм.. требовательное решение.
Значит твое решение хреновое. Ведь рантайм тебе дает кардбланш. И если твое решение ничем не лучше чем аналогичное на обычном С++, значит ты валял дурака или взялся не за то.
A>Что за статистика такая? Мои шпионы говорят, что это не так .
На хотлоге.
A>Нет. Программа должна установиться и работать. Если она не работает, то ее снесут и поставят другую .
Дык другие еще писаться будут.
A>Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой.
Посмотрим. Пока что эта ошибка дала возможность обогнать конкурирующую (хе-хе) разработку на плюсах. Причем объем работ просто несравним.
A>Если говорить в общем — это изрядно сократит количество пользователей этой, вполне возможно, замечательной во всех других отношениях программы.
Опять таки увидим.
A>Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения.
Значит криво установлена. Сам фрймворк не может оказывать влияния на внешние приложения.
A>Мне не понравилось и пришлось снести все это. К тому же .NET-приложения мне показались медленными и прожорливыми. Смена операционной системы неприемлима .
Интересно почему неприемлима? Ну а про меденность это наговоры. Правда про прожорливаость — чистая правда.
A>Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится.
Думаю что после выхода релиза Януса (бжта выдет в бижайшее время) сам увидишь как народ будет качать фрймворк.
Здравствуйте, VladD2, Вы писали:
A>>Нет, не стоит . Выбор .NET в качестве платформы для почтового клиента был большой ошибкой. VD>Посмотрим. Пока что эта ошибка дала возможность обогнать конкурирующую (хе-хе) разработку на плюсах. Причем объем работ просто несравним.
Скорость — это, безусловно, плюс. Но перевешивает ли он минусы, которых немало?
A>>Если говорить о конкретном (моем) случае — то .NET-платформа просто неприемлима. На моем домашнем компьютере стоит Win98 и система после установки фреймворка ведет себя довольно странно, впрочем, как и сам фреймворк и .NET-приложения. VD>Значит криво установлена. Сам фрймворк не может оказывать влияния на внешние приложения.
Ты думаешь? На внешние приложения он, вполнне вероятно, оказывать влияния не может, но вот на систему оказывает и еще как .
A>>Смена операционной системы неприемлима . VD>Интересно почему неприемлима?
i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.
ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.
A>>Специфический таргет-групп — но во многих случаях в настоящее время использование .NET пока не оправданно. Впрочем, через 3-6 лет все, вероятно, изменится. VD>Думаю что после выхода релиза Януса (бжта выдет в бижайшее время) сам увидишь как народ будет качать фрймворк.
A>>>Смена операционной системы неприемлима . VD>>Интересно почему неприемлима?
A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает. A>ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.
Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.
После второго сервис пака глюков конечно меньше стало. Несравнимо меньше. Но вижуал продолжает подглюкивать, хотя всё остальное вроде нормально работает.
Всегда Ваш, PSP.
Re[11]: Производительность Win2k на Duron 800/384...
Здравствуйте, Aquila, Вы писали:
A>>>Смена операционной системы неприемлима . VD>>Интересно почему неприемлима? A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.
Бедняга! По секрету скажу, что дома у меня стоял Celeron 333(o/c 500) с 64МБ памяти! Когда поставил вместо Win98SE Win2k (без всяких сервиспаков, их просто ещё не было), то сразу поразился субъективно возросшей производительности и объективно повысившейся устойчивости!
И сколько после этого мне ни говорили про то, что мол, Win2k начинает шевелиться от 128МБ, я только улыбался в ответ!
В это самое время писался курсовик (веб-сайт) так вОт, одновременно у меня тогда работали Photoshop, DreamWeaver4, FrontPage и HomeSite. Естественно отдельно висели IE, WinCmd, но это Не надо издеваться по поводу такого изобилия средств -- дело не в этом. Дело в том, что меня вполне устраивало время отклика каждой из этих програм при переключении между ними.
Здравствуйте, IT, Вы писали:
VD>>Компонентного программирования — программирование основанное на компонентах, т.е. сборка ПО из готовых блоков. Нечто вроде сборки помпьютеров из комплектующих, но для ПО.
IT>Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль.
Это уже другие компоненты.
Функционально законченный — это необходимо, но еще недостаточно.
Re[12]: Производительность Win2k на Duron 800/384...
Здравствуйте, Хитрик Денис, Вы писали:
ХД>В это самое время писался курсовик (веб-сайт) так вОт, одновременно у меня тогда работали Photoshop, DreamWeaver4, FrontPage и HomeSite. Естественно отдельно висели IE, WinCmd, но это Не надо издеваться по поводу такого изобилия средств -- дело не в этом. Дело в том, что меня вполне устраивало время отклика каждой из этих програм при переключении между ними.
В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого.
ХД>Может что-нибудь в консерватории подправить?
Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .
Здравствуйте, PSP, Вы писали:
PSP>Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.
PSP>После второго сервис пака глюков конечно меньше стало. Несравнимо меньше. Но вижуал продолжает подглюкивать, хотя всё остальное вроде нормально работает.
Что за гнилые, блин, базары ?
Садись за Юникс или Линукс и ковыряйся в консоли, шоб не падоло ничего.
Или запусти для сравнения KDeveloper там же.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, PSP, Вы писали:
PSP>>Согласен. У меня на работе многие смеялись, когда у меня NT 4.0 стояла, а у всех 2k. А я смеялся, когда они вижуал переставляли. Даже от начальника скрывал факт наличия в к-ве оснвной ос NT 4.0.
PSP>>После второго сервис пака глюков конечно меньше стало. Несравнимо меньше. Но вижуал продолжает подглюкивать, хотя всё остальное вроде нормально работает.
OE>Что за гнилые, блин, базары ? OE>Садись за Юникс или Линукс и ковыряйся в консоли, шоб не падоло ничего. OE>Или запусти для сравнения KDeveloper там же.
Я принципиально против таких рассуждений. Если вижуал одинаковый и там и там, нахрен мне глюки иметь. А совместимость всё равно идёт снизу вверх, если я прилаги писать буду под NT4, то под 2k они тем более работать будут..
Всегда Ваш, PSP.
Re[13]: Производительность Win2k на Duron 800/384...
Здравствуйте Aquila, Вы писали:
A>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .
Знаешь, утверждение что W2K на 384М памяти работает меленней 98 мягко говоря неверно.
Здравствуйте AndrewVK, Вы писали:
AVK>Знаешь, утверждение что W2K на 384М памяти работает меленней 98 мягко говоря неверно.
Полностью согласен. У меня до недавнего времени стоял PIII733/384 с 98 и 2K, 2K работал быстрее и надежнее но грузился немного медленней, а если учесть чо 98 падал от каждого чиха... После замены 2K, XP произошли резкие изменения XP грузился быстрее 98, а производительность (после вырубания понтов) выросла относительно 2K надежность тоже. После того как я обнаружил что все программы ради которых я держал 98 после небольших уговоров работают в XP... бедный 98. Плюс у XP есть система востановления после кривых прог и дровдва раза перезагрузился и работаешь дальше, а 2K про 98 я вобще молчу пришлось бы переустонавливать со всеми вытекающими.
ЗЫ на K6 500/128 XP быстрее 98.
2Aquila факты говоря что новые винды быстрее
... << RSDN@Home 1.0 alpha 12 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Производительность Win2k на Duron 800/384...
Здравствуйте, WolfHound, Вы писали:
WH>После замены 2K, XP произошли резкие изменения XP грузился быстрее 98, а производительность (после вырубания понтов) выросла относительно 2K надежность тоже. После того как я обнаружил что все программы ради которых я держал 98 после небольших уговоров работают в XP... бедный 98. Плюс у XP есть система востановления после кривых прог и дровдва раза перезагрузился и работаешь дальше, а 2K про 98 я вобще молчу пришлось бы переустонавливать со всеми вытекающими. WH>ЗЫ на K6 500/128 XP быстрее 98.
Грузится, говоришь, быстрее? А я еще и программы запускаю.
Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения (В конце постинга). Если оппоненты согласны, то дальше будем дискутировать, опираясь на эти определения. Если нет, то попрошу аргументированно оспорить предложенные определения и предложить свои формулировки.
Компонентное программирование
VD> Компонентного программирования — программирование основанное на компонентах, т.е. сборка ПО из готовых блоков. Нечто вроде сборки компьютеров из комплектующих, но для ПО. IT> Компонентом можно упрощённо считать набор связанных классов, реализованных как функционально законченный модуль. OE> Это уже другие компоненты. OE> Функционально законченный — это необходимо, но еще недостаточно. VD> В компонентах главное, что это отчуждаемые модули. Т.е. они должны быть самодостаточны и не требовать наличия исходного кода для своего использования.
OK, так или иначе, но определение компонента есть. ИМХО, не сказали только, что компонент без компонентной инфраструктуры – суть ноль без палочки.
Попробую пояснить свою мысль и сделать кое-какие выводы.
"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.
Инфраструктура может, например, обеспечить скрытие деталей реализации обмена информацией между компонентами (в частности — межпроцессного и межмашинного обмена), предложив свои соглашения, которыми будут пользоваться разработчики модулей. (Аналогия с "железом" — прозрачна. Предлагается, скажем, разъём и параметры напряжения на отдельных штырьках, а откуда эти напряжения берутся — дело разработчиков, например, блоков питания). Также, инфраструктура может обеспечить относительно прозрачный интерфейс для модулей, написанных на разных языках программирования (как в компьютер вставляются блоки от разных производителей), эмулировав тем самым их бинарную совместимость. Возможны и другие функции инфраструктуры.
Модуль, который реализует требования, накладываемые инфраструктурой (а они неизбежно есть), называется компонентом, а сама инфраструктура — компонентной инфраструктурой.
Компонент, удовлетворяющий требованиям инфраструктуры, тем не менее может предъявлять определённые требования к другим компонентам, с которыми он взаимодействует. (Как это справедливо заметил old->*Plutonia_Experiment() )
Другой аспект — отчуждаемость компонента, т.е., компонент, в принципе, может быть помещён в любое окружение, отвечающее спецификации компонентной инфраструктуры. (Приблизительный “железячный”аналог – установка платы на исптытательный стенд).
Третий аспект — любой компонент может быть заменён своим функциональным аналогом, возможно, написанным на другом языке, что не должно повлечь за собой необходимости замены других компонентов системы.
Теперь о компонентно-ориентированном программировании (собственно, о нём, первоначально речь и была).
В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.
Атрибутное (декларативное) программирование
VD> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:
VD>
VD>[MyAtrybut(MyValue)]
VD>void MyMethod(){}
VD>
VD> Вообще атрибуты — это методанные которые могут анализироваться неким кодом (от компилятора, до утилит регисрации) и на базе них можно принимать те или иные решиния.
OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п. Атрибуты, вероятно, характеризуются именем, и типом значения. Кстати, о декларативном программировании – декларативное программирование подразумевает наличие какой-то системы, интерпретирующей декларации. SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.
Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".
Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.
Аспектно-ориентированное программирование
IT> Этот термин ещё толком не сформулировался. Основная идея заключается в отделении мух от котлет. Если алгоритм занимается вычислением логарифма, то ему желательно ничего не знать о транзакциях, модели синхронизации и/или обработки исключений. К тому же эти операции как правило повторяются от раза к разу в различных алгоритмах. Аспектный подход позволяет отделить подобные служебные функции и выделить их в отдельный класс задач. Одним из способов реализации AOP являются атрибуты. К тому же в .NET существует механизм создания классов, все публичные методы которых будут перехватываться специальными обработчиками, которые могут выполнять определённые служебные функции.
OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.
Вот ещё, интересный, на мой взгляд, фрагмент введения к документу "Declarative aspect-oriented programming", взятый с сайта:
Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality. To overcome that problem special languages are used to specify such properties---the so-called aspects---in isolation. The software application is obtained by weaving the aspect code and the implementation of properties corresponding to basic functionality---the so-called components. This paper investigates the suitability of functional meta-programs to specify aspects and to perform weaving. The proposal focuses on the declarative paradigm (logic programming, attribute grammars, natural semantics, constructive algebraic specification etc.) as far as components are concerned, whereas aspects are represented by program transformations. Weaving is regarded as a program composition returning a combination of the components satisfying all the aspects. The computational behaviour of the components is preserved during weaving. The proposal improves reusability of declarative programs. The approach is generic in the sense that it is applicable to several representatives of the declarative paradigm. Several roles of aspect code are defined and analysed.
AOP нацелено на проблему реализации таких свойств как обработка ошибок и оптимизация, пронизывающих основную функциональность [программы]. Для решения этой проблемы используются специальные языки, независимо определяющие эти свойства (так называемые — аспекты). Прикладная программа обрабатывается «сшиванием» [weaving] аспектного кода и реализаций указанных свойств в соответствии с базовой функциональностью (т.н. — компоненты). Настоящий документ исследует пригодность функционального метапрограммирования для специфицирования аспектов и выполнения «сшивания». Предложение фокусируется на декларативной парадигме (логическое программирование, атрибутные грамматики, естественные семантики, конструктивные алгебраические спецификации и т.п.) и компонентах, тогда как аспекты представлены трансформацией программы. «Сшивание» представляется композицией, являющейся комбинацией компонентов, удовлетворяющих всем аспектам. Вычислительное поведение компонента после «сшивания» сохраняется неизменным. Предложение повышает степень повторного использования декларативных программ. Подход, по сути является обобщённым, поскольку применим к разным представлениям [representatives] декларативной парадигмы. Определён и проанализирован ряд ролевых функций аспектного кода.
Значит, таким образом, цепочка замыкается – от AOP (цель) к атрибутам и компонентам(средство).
*****************************************************************
Итак, попробую дать определения для различных «программирований».
*****************************************************************
Компонентно-ориентированное программирование.
Подход к разработке, ориентированный на использование разных языков программирования, в рамках какой-либо компонентной инфраструктуры. Подход, в основном, нацелен на реализацию независмого распространения компонентов.
Примеры инфраструктур: COM, Corba Component Model (CCM), Любые plug-ins – тоже, в сущности, компоненты.
Атрибутное программирование.
Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.
Аспектно-ориентированное программирование.
Совокупность подходов и средств, предусматривающих независимую реализовацию различной, например — прикладной и инфраструктурной [часто встречающийся термин "cross-cutting" я перевёл как «пронизывающей»] функциональности системы. Такие реализации называются аспектами. Подразумевает наличие средства, компонующего [weaving] аспекты в единое целое. Наличие такого средства требует, чтобы аспекты были снабжены определёнными декларациями, на основе которых выполняется компоновка.
Ну вот так или примерно так. Теперь жду ваших мнений.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Терминология (weaving, separation of concerns)
Здравствуйте, Геннадий Васильев, Вы писали, и мне понравилось как
Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns.
Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".
Насчет SoC я ни до чего путного недодумался.
Понятно, что у решаемой задачи есть различные стороны (аспекты), которым следует уделить внимание ("побеспокоиться"). В AOP культивируется техника их разделения, вследствие их относительной независимости, с последующим переплетением (weaving). Так как следет переводить этот термин???
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения (В конце постинга). Если оппоненты согласны, то дальше будем дискутировать, опираясь на эти определения. Если нет, то попрошу аргументированно оспорить предложенные определения и предложить свои формулировки.
Провокатор?
ГВ>"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.
Почему именно бинарной? Корба или веб-сервисы как то без обходиться. И никаких согласователей там не наблюдается.
ГВ>Третий аспект — любой компонент может быть заменён своим функциональным аналогом, возможно, написанным на другом языке, что не должно повлечь за собой необходимости замены других компонентов системы.
Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?
ГВ>В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.
Про языки см. выше.
VD>> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:
На определение не катит. Атрибуты тоже прописываются в коде. И еще — Атрибутное ... — ... ввиде атрибутов. Это как:
Что такое компилятор? Эта такая программа которая компилирует. А что такое компилировать? Это то что делает компилятор.
Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.
ГВ>OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п.
Прежде всего внутренними. Компилятор шарпа кстати тоже написан на шарпе и работает в CLR.
ГВ>Атрибуты, вероятно, характеризуются именем, и типом значения.
Не так примитивно. Атрибуты это классы, экземпляры которых создает компилятор, когда встречает в исходном коде их использование. Соответственно атрибут может нести целую кучу значений и связанным с ними кодом.
ГВ>SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации.
Пролог не декларативный, в отличие от SQL92. Это продукционный язык. Более известный аналог — язык шаблонов XSLT. Да и sql декларативный только то что в стандарте. Реальные языки, вроде transact sql или pl/sql имеют как декларативную так и экзекутивную часть.
ГВ>Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".
Что ты понимаешь под семантикой атрибутов?
ГВ>Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.
Это можно сказать про очень много видов программирования. Не в этом изюминка атрибутов. Атрибутное программирование это прежде всего программирование метаданных. Другой вид такого программированиия — часть Reflection.Emit, так которая не касается собственно IL опкодов.
ГВ>OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.
Непонятно.
ГВ>
ГВ>Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality.
Проблема разделения продукционного кода и обработки ошибок сродни мсовскому dll hell Столько уже для этого напредлагали, говоря что вот наконец решили, а потом опять. Те же исключения из той же оперы.
ГВ>Компонентно-ориентированное программирование.
ГВ>Подход к разработке, ориентированный на использование разных языков программирования,
Как я уже говорил — в корне неверно
ГВ>Corba Component Model (CCM)
Это неофициальный термин по моему. Официально CORBA 3.
Здравствуйте Anton V. Kolotaev, Вы писали:
AVK>Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns. AVK>Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".