Не знаю как нащёт моны, но вот сейчяс прикодится с асп.нетом якшаться, всё время удивляюсь: ужель наносуксь никогда-никогда прог не научится делать? Вроде бы пора уже...
Моно игрушка неплохая, однако список JIT для разных платформ не столь широк, как для Java. Без JIT - это всего лишь игрушка. Хотя пусть развивается, если кому-то интересно. Может и функциональные язычки программирования получат распространение для .NET и mono. По крайней мере Just for Fun, на радость господину Луговскому.:) Мне же Java вполне достаточно. Я "развиваюсь" в сторону АОП-расширений. IMHO, AOP будет весьма распространен в течение ближайших 5 лет.
Тем, что средства АОП - тривиально реализуются (а чаще - просто заменяются) макрами, однако обратное - неверно. Макры - более общее решение для тех же проблем.
>Тем, что средства АОП - тривиально реализуются (а чаще - просто заменяются) макрами, однако обратное - неверно. Макры - более общее решение для тех же проблем.
Если заменить решение, основанное на Spring AOP, на решение, основанное на макросах, то это будет другое решение. Совсем. Или я просто в упор не вижу, чем же Spring AOP похож на макросы.
По сути, это просто хитрый динамический загрузчик. Грузим некий сервис, зовем метод, а по пути вызов перехватывается и как-то отдельно обрабатывается перед передачей (или после) целевому сервису. Где тут макросы? Ни вызывающего сервис, ни сам сервис править не можем - ни тот, ни другой о перехвате не знает.
a.secured()
public void secured() {
// Some secured operation...
}
С помощью Spring AOP можно сделать так, что вызов метода secured будет сопровождаться некоторой проверкой (например, проверкой credentials-ов). Куда макрос пихать будем? Место вызова править не можем, оно не должно зависеть от наличия/отсутствия проверки. Вызываемый сервис - аналогично.
Семантика различается - для АОП изменения в runtime, для макр - ещё при компиляции, но для программиста всё будет выглядеть совершенно одинаково - как АОП расширяет язык, сохраняя синтаксис, так и с макрами мы просто вклиниваемся в определения методов и классов, подставляя дополнительный код вокруг. Аналогично контрактное программирование реализуется либо на уровне языка (или препроцессора, как и AspectJ), либо на уровне макр, подменяющих конструкции для определения методов. Но с макрами ты можешь сделать много всякого другого, а с одним только АОП далеко не уедешь, при том, что АОП разделяет недостатки метапрограммирования - затруднённую отладку. Так если фичей больше, а недостатки те же - то лучше выбирать более универсальное решение. Так что лично мой выбор - AspectJ - фтопку, Jatha - рулит.
>Семантика различается - для АОП изменения в runtime, для макр - ещё при компиляции
?
Иначе я с таким же успехом могу сказать, что все есть подмножество машины Тьюринга, ведь не ней тоже можно любую задачу решить (пусть и совсем другим способом).
Пример, приведенный выше демонстрирует использование Spring AOP для уменьшеня связности компонентов (т.е для уменьшения цены переиспользования и модификации), т.е для вполне конкретной цели. Я считаю, что в данной ситуации макросы таким плюсом обладать не будут.