Здравствуйте, IT, Вы писали:

AVK>>Правильный АОП должен уметь накладываться на уже скомпилированную сборку, ничего ни про какой АОП не знающую.

IT>С каких это пор появились такие требования к АОП?

Требования к реализации АОП. Иначе львиную долю полезности АОП теряет.

Здравствуйте, AndrewVK, Вы писали:

IT>>С каких это пор появились такие требования к АОП?

AVK>Требования к реализации АОП. Иначе львиную долю полезности АОП теряет.

Я так не думаю. Впрочем, не исключаю, что для небольшого круга задач это справедливо.

Здравствуйте, IT, Вы писали:

IT>Я так не думаю.

Ну а я думаю.

IT> Впрочем, не исключаю, что для небольшого круга задач это справедливо.

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

Здравствуйте, AndrewVK, Вы писали:

IT>> Впрочем, не исключаю, что для небольшого круга задач это справедливо.

AVK>Полезность в качестве универсального средства решения всех задач АОП уже наглядно продемонстрировал.

С этим никто и не спорит. Для меня под большим сомнением твоё утверждение, что АОП рулит только, когда накладывается на уже скомпилированную сборку. Повторю ещё раз. Возможно это справедливо для небольшого круга задач, где действительно необходимо конфигурирование системы во время деплоймента. Но такие решения не являются широко применяемой практикой и скорее относятся к экзотическим. Для обычных задач АОП точно так же рулит не по-децки, если его применять с умом. Никакой разницы между применения его к уже скомпилированной или ещё нет сборке я не вижу в принципе.

AVK>В задачках оборачивания прикладного кода системными средствами внутри некоей инфраструктуры АОП рулит неподецки. Но тама как правило нужен деплоймент как отдельный этап или как отдельная процедура в рантайме. А в остальном АОП зачастую выступает в роли китайской артиллерии для нанесения вреда поголовью пернатых из семейства врановых.

Весьма однобокий взгляд, основанный, скорее всего, на однобоком опыте. Мне почему-то великолепно удаётся применяется АОП без всяких отдельных деплойментов.

Здравствуйте, IT, Вы писали:

IT>С этим никто и не спорит. Для меня под большим сомнением твоё утверждение, что АОП рулит только, когда накладывается на уже скомпилированную сборку.

Тут, как раз, все очень просто. Возможность работать с скомпилированной сборкой определяет совместимость с КОП. Это как нетовские дженерики vs плюсовые шаблоны. Если забить на КОП, то и АОП, работающая в компайл-тайме, будет приемлемым. Но на такое забивание в рамках .NET должно быть очень серьезное основание. Поэтому мне и кажется, что АОП, не способное работать с скомпилированным кодом, в качестве универсального фреймворка имеет очень небольшуюценность.

IT> Повторю ещё раз. Возможно это справедливо для небольшого круга задач, где действительно необходимо конфигурирование системы во время деплоймента. Но такие решения не являются широко применяемой практикой и скорее относятся к экзотическим.

Ну я бы так не сказал.

IT> Для обычных задач АОП точно так же рулит не по-децки, если его применять с умом.

Только я пока не видел этого рулящего неподецки применения АОП в компайл-тайме.

IT> Никакой разницы между применения его к уже скомпилированной или ещё нет сборке я не вижу в принципе.

С точки зрения применения техник МП разница принципиальная.

IT>Весьма однобокий взгляд, основанный, скорее всего, на однобоком опыте.

Ну понеслась. Только теперь тем, что я первый начал ты не отмажешься. Сдается мне, это твой опыт однобок, коль скоро деплоймент тебе кажется убогим.

IT> Мне почему-то великолепно удаётся применяется АОП без всяких отдельных деплойментов.

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

AndrewVK wrote:
> IT> Для обычных задач АОП точно так же рулит не по-децки, если его
> применять с умом.
> Только я пока не видел этого рулящего неподецки применения АОП в
> компайл-тайме.
Дело в том, что для Java/.NET нет особого смысла делать AOP на этапе
компиляции (хотя AspectJ именно так и работает). Наоборот, даже ПРОЩЕ
делать weaving в runtime'е. Но это не значит, что AOP принципиально не
может работать без deployment'а.

И использование AOP на любом коде тоже необязательно. Например, в Java
очень часто используют аннотации для обозначения pointcut'ов.

Здравствуйте, IT, Вы писали:

IT>Если не вдаваться в детали реализации, то АОП — это определённый тип паттернов, называемых аспектами. Если их реализовывать средствами МП, то они не перестанут от этого быть аспектами.

Проблема в том, что АОП в том виде в котором он задуман и реализован — это очень убогая технология. В ней нет главного — возможности порождать гибкий и адаптируемый код. А тупое "прививание" готовых фрагментов кода дает слишком малый простор для фантазии.

Так что конечно МП можно использовать для релазации АОП, но если при этом ограничиваться только этим, то ничего хорошего не выйдет.

Так что из АОП можно взять только саму идея внедрения кода в разные части рукописного кода. Но это настлько примитивная возможность, что ее даже нет смысла рассматривать отдельно. В общем, на парадигму это никак не тянет.

Здравствуйте, Odi$$ey, Вы писали:

OE>всем ссылочным полям и полям полей объекта до десятого колена? так же просто как завернуть все указатели в какой-нибудь smart_ptr и перестать "контролировать время жизни объектов вручную"

Это называется глубоко клонирование. Оно нужно не часто, но реализвоать его не так сложно. Просто нужно чтобы все объекты входящие в граф поддерживали глубокое клонирование. Далее остается только вызвать метод Clone рекурсивно.

Ну, а в большинстве случаев вообще подходит поверхностноне клонирование.

VD>>И если это вдруг действительно головная боль, то куда она девается если изчезает GC?

OE>все передается по-значению, копию имеем автоматом.

Я извиняюсь, но в чем проблема все что нужно так же передавать по значению при наличии GC?

OE>Но ты прав, головная боль от исчезновения GC никуда не девается, как впрочем и от его появления,

От его появления с тебя снимается огроманя ноша. Но понять теоритически это могут только еденицы. Остальным нужно долго испытвать это на своей шкуре.

OE>Так что мы имеем с GуCя? вместо простого знания, что память не освободится, пока мы ее не освободим и связанной с этим (немаленькой, согласен) головной боли имеем необходимость знания нетривиальных алгоритмов GC, особенностей реализации в этом отношении объектов, и surprise! все еще необходимое ручное управление освобождением памяти, правда теперь уже в виде исключений, но голова от этих исключений болит ничуть не меньше чем от правил

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не примазывайся.

К чему Гена? Какой смысл примазываться к тому от чего тебе блевать охота?

Здравствуйте, VladD2, Вы писали:

VD>Так что из АОП можно взять только саму идея внедрения кода в разные части рукописного кода. Но это настлько примитивная возможность, что ее даже нет смысла рассматривать отдельно. В общем, на парадигму это никак не тянет.

С этим я согласен. Поэтому и предпочитаю называть это не парадигмой, а типом паттернов.

Здравствуйте, AndrewVK, Вы писали:

AVK>Тут, как раз, все очень просто. Возможность работать с скомпилированной сборкой определяет совместимость с КОП. Это как нетовские дженерики vs плюсовые шаблоны. Если забить на КОП, то и АОП, работающая в компайл-тайме, будет приемлемым.

Всё смешалось в доме Облонских Причём тут КОП вообще? Совместимость с КОП, это, конечно же, очень здорово, только я что-то впервые слышу, что АОП без КОП не имеет смысла.

AVK>Но на такое забивание в рамках .NET должно быть очень серьезное основание. Поэтому мне и кажется, что АОП, не способное работать с скомпилированным кодом, в качестве универсального фреймворка имеет очень небольшуюценность.

Это тебе только кажется. Идея АОП в разделении сквозного кода от бизнес-логики. КОП здесь никаким боком и может учитываться только при рассмотрении конкретной реализации.

IT>> Повторю ещё раз. Возможно это справедливо для небольшого круга задач, где действительно необходимо конфигурирование системы во время деплоймента. Но такие решения не являются широко применяемой практикой и скорее относятся к экзотическим.

AVK>Ну я бы так не сказал.

О подобных архитектурных решениях я слышал только от тебя. И я ничего не имею против этого и вполне допускаю, что в твоём конкретном случае это было единственно правильное решение. Вот только я не понимаю почему ты считаешь, что это решение должно быть единственно правильным и для всех остальных

IT>> Для обычных задач АОП точно так же рулит не по-децки, если его применять с умом.

AVK>Только я пока не видел этого рулящего неподецки применения АОП в компайл-тайме.

Потому что для этого пока нет соответствующих средств.

IT>> Никакой разницы между применения его к уже скомпилированной или ещё нет сборке я не вижу в принципе.

AVK>С точки зрения применения техник МП разница принципиальная.

Ну и что? Это же всего навсего реализация.

IT>>Весьма однобокий взгляд, основанный, скорее всего, на однобоком опыте.

AVK>Ну понеслась. Только теперь тем, что я первый начал ты не отмажешься. Сдается мне, это твой опыт однобок, коль скоро деплоймент тебе кажется убогим.

Может дашь ссылочку где я это утверждал? В отличии от некоторых я отношусь к своему опыту критически и не склонен зацикливаться на одном решении для всех подряд решаемых мной задач. И уж утвержать такую, простите, чушь, как АОП хорош только совместно с КОП или только без КОП я уж точно не буду, т.к. в разных ситуациях решения могут быть принципиально разными.

IT>> Мне почему-то великолепно удаётся применяется АОП без всяких отдельных деплойментов.

AVK>Это в BLToolkit то?

У тебя есть какие-то конкретные притензии к BLToolkit? Высказывай, не стесняйся.

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

Ещё раз повторяю специально для тех, кто в танке. Я не считаю себя вправе навязывать другим своё видение архитектуры вообще и решать за людей что для них лучше, использовать XML или атрибуты, в частности. BLToolkit позволяет использовать любой из способов, совместно оба или даже изобрести свой собственный. И личное дело каждого какое решение использовать в каждом конкретном случае. Поверь мне, люди вполне нормально с этим справляются, особенно, если к ним не лезут со всякими дурацкими советами, основанными на личном восприятии мира, увиденного лишь через одну замочную скважину.

Здравствуйте, IT, Вы писали:

IT>С этим я согласен. Поэтому и предпочитаю называть это не парадигмой, а типом паттернов.

Можно назвать и так. Только он недодуманный, что ли. В АОП сказано "А", но не сказано "Б", то есть, выдвинута идея о том, что есть некая сквозная функциональность которую можно прикливать куда нужно по контесту, но не проработано то как формировать прикрпеляемый код. А меж тем, в большинстве задач вопрос формирования кода куда важнее самого прикрепления. Потому как просто готовый код почти никогда не может быть полезен. Ну, разве что для логирования. Вот и получается, что все статьи по АОП на этом логировании просто таки зациклены.

VladD2 wrote:
> IT>Если не вдаваться в детали реализации, то АОП — это определённый тип
> паттернов, называемых аспектами. Если их реализовывать средствами МП, то
> они не перестанут от этого быть аспектами.
> Проблема в том, что АОП в том виде в котором он задуман и реализован —
> это очень убогая технология.
Ну да, как и все ООП. Добавили, понимаешь, диспатчинг через виртуальную
таблицу и считают себя целой парадигмой.

> В ней нет главного — возможности порождать гибкий и адаптируемый код.
А для АОП это совсем и не нужно.

> Так что конечно МП можно использовать для релазации АОП, но если при
> этом ограничиваться только этим, то ничего хорошего не выйдет.
На самом деле, для АОП вообще почти не нужно средств
метапрограммирования. Даже больше, я бы сказал, что АОП вообще не
относится к метапрограммированию (т.е. к "программам, которые делают
программы").

Тем не менее, AOP доказал свою полезность в определенных областях. А на
приз имени серебряной пули он вроде и не номинировался.

> Так что из АОП можно взять только саму идея внедрения кода в разные
> части рукописного кода. Но это настлько примитивная возможность, что ее
> даже нет смысла рассматривать отдельно. В общем, на парадигму это никак
> не тянет.
Ну да, возможность примитивная — как и диспатчинг методов по виртуальной
таблице. Или возможность квази-цитирования.

Hello, c-smile!
You wrote on Sun, 03 Jun 2007 05:52:02 GMT:

c>>> Посылка неправильная. Java разработка не быстрее чем
c>>> разаработка на X, Y, Z.
c>>> Ровно столько же занимает (9 месяцев в среднем на проект).

YК>> Это как средняя температура по больнице, да?

c> По моей собственной больнице, да.

c> Из тех реальных проектов которые мне известны на Java все
c> достаточно ёмкие.

c> Тут проблема даже не в Java а в некоем вселенском принципе "проект
c> должен вызреть".

c> Если есть сомнения по поводу девяти месяцев — назови реальный
c> проект — будет предметный разговор.

Дело не в девяти месяцах, а в бессмысленности показателя "среднее время длительности проекта" без выделения общих характеристик проектов. Для чего его можно использовать? Ты вот использовал этот показатель для сравнения скорости разработки на Java и С++, не учтя даже, что применяются эти языки большей частью в разных предметных областях.

Здравствуйте, Cyberax, Вы писали:

C>Дело в том, что для Java/.NET нет особого смысла делать AOP на этапе
C>компиляции (хотя AspectJ именно так и работает). Наоборот, даже ПРОЩЕ
C>делать weaving в runtime'е. Но это не значит, что AOP принципиально не
C>может работать без deployment'а.

А разве я говорил что он не может работать без деплоймента? Я немножко другое говорил — смысла в нем без рантайма не очень много.

Здравствуйте, IT, Вы писали:

IT>Всё смешалось в доме Облонских Причём тут КОП вообще?

При том, что и Java, и .NET среды компонентные.

IT> Совместимость с КОП, это, конечно же, очень здорово, только я что-то впервые слышу, что АОП без КОП не имеет смысла.

А я и не говорил этого. Имеет конечно, но в рамках компонентных сред несовместимость с КОП налагает существенные ограничения.

AVK>>Но на такое забивание в рамках .NET должно быть очень серьезное основание. Поэтому мне и кажется, что АОП, не способное работать с скомпилированным кодом, в качестве универсального фреймворка имеет очень небольшуюценность.

IT>Это тебе только кажется.

Естественно.

IT>Идея АОП в разделении сквозного кода от бизнес-логики.

Смешно. Видишь ли, разделение сквозного кода от бизнес-логики, оно конечно здорово, но это нифига не АОП, это куда более общий принцип. Согласно этой идее строятся и практически все структурные паттерны GoF, и MVC/MVP, и IoC контейнеры, и куча всяких фреймворков (WCF к примеру, или даже банальный ремоутинг).
Так что я совсем не против советсеой власти.


AVK>>Ну я бы так не сказал.

IT>О подобных архитектурных решениях я слышал только от тебя.

Тут, в этом топике, как минимум JBoss поминали, причем не я.

IT> И я ничего не имею против этого и вполне допускаю, что в твоём конкретном случае это было единственно правильное решение.

При чем тут мой случай? Я вобще что то про свой случай говорил?

IT> Вот только я не понимаю почему ты считаешь, что это решение должно быть единственно правильным и для всех остальных

Потому что меня пока не убедил никто в обратном.

AVK>>Только я пока не видел этого рулящего неподецки применения АОП в компайл-тайме.

IT>Потому что для этого пока нет соответствующих средств.

А, ну ну. Яйца, значит, мешают.

AVK>>Ну понеслась. Только теперь тем, что я первый начал ты не отмажешься. Сдается мне, это твой опыт однобок, коль скоро деплоймент тебе кажется убогим.

IT>Может дашь ссылочку где я это утверждал?

Что утверждал?

IT> В отличии от некоторых я отношусь к своему опыту критически

Заметно. Почему то ты с завидной регулярностью скатываешься на подобные аргументы.

AVK>>Это в BLToolkit то?

IT>У тебя есть какие-то конкретные притензии к BLToolkit? Высказывай, не стесняйся.

Притензий нет. Только там аспекты того, динамические.

IT>Ещё раз повторяю специально для тех, кто в танке. Я не считаю себя вправе навязывать другим своё видение архитектуры вообще и решать за людей что для них лучше, использовать XML или атрибуты, в частности.

Это понятно. Но ведь что то тея заставило реализовать такое решение, не так ли?

IT>Поверь мне, люди вполне нормально с этим справляются, особенно, если к ним не лезут со всякими дурацкими советами, основанными на личном восприятии мира, увиденного лишь через одну замочную скважину.

Да, аргументики у вас, однако.

Здравствуйте, AndrewVK, Вы писали:

IT>>Всё смешалось в доме Облонских Причём тут КОП вообще?
AVK>При том, что и Java, и .NET среды компонентные.

Они ещё и объектно-ориентированные и обе используют JIT, что означает, что АОП не имеет смысла без ООП и особенно без JIT.

IT>> Совместимость с КОП, это, конечно же, очень здорово, только я что-то впервые слышу, что АОП без КОП не имеет смысла.
AVK>А я и не говорил этого. Имеет конечно, но в рамках компонентных сред несовместимость с КОП налагает существенные ограничения.

Да абсолютно никаких. Разве что только в твоих задачах.

IT>>Идея АОП в разделении сквозного кода от бизнес-логики.

AVK>Смешно. Видишь ли, разделение сквозного кода от бизнес-логики, оно конечно здорово, но это нифига не АОП, это куда более общий принцип. Согласно этой идее строятся и практически все структурные паттерны GoF, и MVC/MVP, и IoC контейнеры, и куча всяких фреймворков (WCF к примеру, или даже банальный ремоутинг).
AVK>Так что я совсем не против советсеой власти.

Покури тогда, что ли, определение АОП Я даже не знаю что и посоветовать в данном случае.

AVK>>>Ну я бы так не сказал.
IT>>О подобных архитектурных решениях я слышал только от тебя.

AVK>Тут, в этом топике, как минимум JBoss поминали, причем не я.

Где именно?

IT>> И я ничего не имею против этого и вполне допускаю, что в твоём конкретном случае это было единственно правильное решение.
AVK>При чем тут мой случай? Я вобще что то про свой случай говорил?

Т.е. про твой?

IT>> Вот только я не понимаю почему ты считаешь, что это решение должно быть единственно правильным и для всех остальных
AVK>Потому что меня пока не убедил никто в обратном.

Анекдот про Неуловимого Джо ещё помнишь?

AVK>>>Только я пока не видел этого рулящего неподецки применения АОП в компайл-тайме.
IT>>Потому что для этого пока нет соответствующих средств.

AVK>А, ну ну. Яйца, значит, мешают.

Не яйца, а кость вместо мозга у некоторых товарищей.

AVK>>>Ну понеслась. Только теперь тем, что я первый начал ты не отмажешься. Сдается мне, это твой опыт однобок, коль скоро деплоймент тебе кажется убогим.
IT>>Может дашь ссылочку где я это утверждал?
AVK>Что утверждал?

См. выделенное из тобой же написанного.

IT>> В отличии от некоторых я отношусь к своему опыту критически
AVK>Заметно. Почему то ты с завидной регулярностью скатываешься на подобные аргументы.

На аргументы я скатываюсь, когда меня начинают необоснованно обвинять в том, чего я никогда не делал и додумывать за меня то, что я никогда не думал.

AVK>>>Это в BLToolkit то?
IT>>У тебя есть какие-то конкретные притензии к BLToolkit? Высказывай, не стесняйся.
AVK>Притензий нет. Только там аспекты того, динамические.

Это всего лишь реализация. Сделаем версию для Nemerle будут статические.

IT>>Ещё раз повторяю специально для тех, кто в танке. Я не считаю себя вправе навязывать другим своё видение архитектуры вообще и решать за людей что для них лучше, использовать XML или атрибуты, в частности.

AVK>Это понятно. Но ведь что то тея заставило реализовать такое решение, не так ли?

Ещё в RFD после опубликования статьи на CodeProject народ развил бурную дискуссию на эту тему. А в BLToolkit XML был с самого начала. При этом некоторым хотелось странного — XML, но в ресурсах, чтобы лишние файлы где попало не болтались. Странный подход, не так ли? И, кстати, в основном народ просил XML ссылаясь на Java, но в ней на тот момент атрибутов вообще не было.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Odi$$ey, Вы писали:

OE>>головная боль тут-же возвращается, как только нужно передать копию объекта

VD>И в чем тут головная боль? Сложно написать метод Clone?

Проблема в том, что в .NET-языках нет семантики владения для ссылочных типов.
Если у нас есть член класса

private SomeClass _member;

то нам, вообще говоря, не ясно является этот член разделяемым объектом или же он принадлежит данному классу (и при клонировании его надо клонировать). Тут уже придется разбираться в каждом конкретном случае.

В С++ же проще:

MyClass1                                         _member1; // этим мы владеем
boost::shared_ptr<MyClass2> _member2; // этот мы разделяем

, при этом по умолчанию сгенерируется правильный конструктор копирования. Правда с полиморфным копированием уже хуже . Нужен clone_ptr и реализация виртуального метода clone (правда, тривиальная) во всех объектах.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Blazkowicz, Вы писали:

B>>Вот это-то и расстраивает. Я всего месяц работаю с удаленной .NET командой и уже раза 3 слышал от них что во всех бедах виноват MS.

L>Не обращай внимание. Это традиция — винить во всех бедах микрософт.

Ну их за дело ругают . Плохо только то, что МС эти баги даже не исправляет.

Здравствуйте, VladD2, Вы писали:

VD>Тогда только на С++ не выйдет. Есть только Рефлекторовский и Моновский. Вроде оба на Шарпе.

Есть еше Abstract IL Toolkit. Но он тоже managed.