Ответ на »сообщение 3585« (К)
___________________________

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...
Ой, что сейчас начнется... :)
Дейкстра как раз доказывал, что императивное программирование может быть математически точным. Это только что в этом форуме упоминалось. Так, что сейчас получите по полной программе...

Ответ на »сообщение 3584« (info21)
___________________________
Не к математике, а к представлениям о ней людей, ее не понимающих. Таких, разумеется, подавляющее большинство, всюду.
Например, к таковым, без сомненья, можно отнести Дейкстру и Бэкуса...

Ответ на »сообщение 3543« (Jack Of Shadows)
___________________________

... но ФП всегда было сильно именно в академической среде. Все таки самая близкая к математике.


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

Ответ на »сообщение 3582« (AVC)
___________________________
сомнительные места обобщенного программирования.
Не усёк, где оные сомнительные места?

Интересно, что через странности аспектного подхода как-то начинают вырисовываться сомнительные места обобщенного программирования.
IMHO, что-то есть у них общее...

Как думаете?

Ответ на »сообщение 3580« (Илья Ермаков)
___________________________

Пример, который привел Jack,

pointcut before *.SSN SecureSSN

где аспект навешивается по любые поля, называющиеся SSN, напомнил мне известный отрывок из "Алисы в стране чудес":

"They were learining to draw", the Dormouse went on, yawning and rubbing its yeys, for it was getting very sleepy; "and they drew all manner of things -- everything that begins with an M --"
"Why with an M?" said Alice.
"Why not?" said the March Hare.
Alice was silent.

:)

Ответ на »сообщение 3571« (AVC)
___________________________

Ответ на »сообщение 3566« (Jack Of Shadows)
Все это вызывает у меня определенные сомнения.
Метод, позволяющий менять любую деталь в отдельности, -- вряд ли хороший метод программирования, т.к. нет способа обеспечить программные инварианты.
Обязательно должны быть ограничения и какие-то "нельзя".

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

Ответ на »сообщение 3569« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3568« (AVC)
___________________________
Они вытекают из принципа higher order functions.
По существу вы передаете метод класса (функцию) как параметр в другую функцию (аспект)
При чем делаете это в декларативном виде. ТО есть описываете взаимосвязи через pointcuts а не передаете методы явно в коде.

То же самое в модульной парадигме. Только взаимосвязи описываются через pointcuts на инсталлируемых разъемах модулей.

Ответ на »сообщение 3567« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3563« (Илья Ермаков)
___________________________
Илья мы это уже слышали, в обсуждении конструкторов. Все через фабрики обьектов.
Действительно, при правильном проектировании проблем не бывает. :))
Так можно что хош отрицать. И конструктора, и аспекты, и сборшик мусора, и обработку исключений.
При правильном проектировании всего этого просто не должно быть :))

Джек, Вы иногда, простите, как маленький ребенок (хотя я допускаю, что в плане каких-то обсуждений ФП я могу выглядеть так же) :-)
Есть набор общих средств и архитектурных методологий, который мы называем (с легкой руки Руслана) "кластерно-модульное программирование". Эти средства/методологии нацелены на построение модульных компонентных систем, как можно более гибко расширяемых (в частности, на лету), при этом с упором на надежность и обозримость.

Аспекты в общем смысле можно трактовать как введение модификаций, "флуктуаций" в уже существующую систему без вмешательства в ее внутреннее устройство. Кластерно-модульное программирования на эту задачу и нацелено. Я Вам показал, как универсальными механизмами решается конкретная узкая задача - "аспектирование" отдельно взятого класса. Решение это общее, дающее много других совокупных эффектов. Никаких "дыр" в нем нет. Если угодно продолжать язвить по поводу конструкторов, то будьте любезны - покажите пальчиком, как в моем примере пользователь может обойти фабрику (Вы все упорно твердили, что может...).

Аспекты как узкий механизм АОП и подобная "требуха" - это "бубны", которые задним числом "клепаются", чтобы решить проблемы, вызванные невежеством в проектировании среднестатического массового программиста. Народ не понимает идеи с долгоидущим эффектом, народ не понимает, что приложив чуть больше усилий к грамотной разработке сегодня, он получит большой совокупный эффект завтра... Народу подавай волшебные лекарства, которые позоволят меньше думать... :-)
Но если не уметь пользоваться базисными, универсальными средствами - то "припарок" на каждый чих не напасешься... Вчера то, сегодня это (..самое АОП), что будет завтра? Зато на томах макулатуры легко зарабатываются деньги... :-)

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

Ответ на »сообщение 3571« (AVC)
___________________________
Больше всего напоминает мощный специализированный препроцессор.
AspectJ кстати препроцессор. А вот ApsectWerks сделана как библиотека.
Все это вызывает у меня определенные сомнения.
Вызывает сомнения - не пользуйтесь. Кому понадобится, те воспользуются.
Я например не пользуюсь. Вместо этого просто ушел в лисп.