Аспектно-ориентированное программирование (АОП) - это прадигма, выделяющая в самостоятельные сущности элементы сквозной функциональности. Викепедия относит сюда, например, логирование, которое требуется реализовать сразу во всём проекте. Посоветуйте литературу. Особенно интересует встраивание аспектно-ориентированной подсистемы логирования в проект, весь остальной текст которого писан в объектно-ориентированной парадигме.

Была неплохая вроде бы книжка, не Сафонов, вспомню - напишу.
В общем случае встроить АОП в традиционный язык можно лишь с привлечением инструментальных средств (типа AspectJ).
В С++ часть АОП может быть эмулирована шаблонами (неплохой близкий к теме пример - boost::operators), добавляя требуемый код (aka mixins) в конструкторы и прочие методы.

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

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 13:14

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

только тема эта не про С++

Если язык достаточно развит для того, чтоб на нём написать класс потока ввода-вывода, то не зачем вводить поток в сам язык. Но сама возможность описывать классы должна быть свойствами языка. Ключевое слово class - часть языка, также как и управление видимостью членов, оператор точка в значении доступ к члену, неявный параметр метода и тому подобные особенности языка, а не написанного на нём класса. Это и есть поддержка объектно-ориентированной парадигмы, а конкретный (в обыденном смысле) класс такие языковые возможности их только использует. Так вот, непосредственно в язык должна быть встроена поддержка парадигмы, а то, что можно будет в этой парадигме написать на самом языке, на нём и должно быть написано и частично включено в дистрибутив, а частично будет самими проектами. Проблема в том, что я вообще не ориентируюсь даже в аспектно-ориентированном проектировании, тем более не знаю, чем поддерживать эту парадигму, а какие языковые возможности к ней не относятся.

Добавлено через 2 минуты и 19 секунд
Вот именно.

зачем тогда эти разговоры о новом языке?

в третий раз навожу на мысль: mixin как наиболее простое и общее понятие в русле АОП 

Кажется понял. Примеси позволяют по разу реализовать каждый из операторов: <, <=, ==, >=, > и != сразу для всех классов, а в каждом классе один раз реализовать оператор "как относятся", возвращающий один из трёх результатов: левый меньше правого, операнды равны и левый больше правого? То есть идея в том, что если некоторые методы и операторы можно вывести из других, то выводимые методы и операторы можно реализовать один раз сразу для всех классов, имеющих в своих интерфейсах те методы и операторы, из которых они выводятся? Этого достаточно для поддержки аспектно-ориентированного программирования?

Добавлено @ 17:08
Ну вообще то аспекты - это не всё и не ради них он задуман. В "науке и жизни" когда то публиковались статьи о языке "рапира", где значение пишется слева, а куда надо присвоить справа и авторы умудрялись считать, что так проще. У меня будут одновременно левое и правое присваивание, при этом их будет легко различить и запомнить. А ещё будут отдельные от ввода-вывода операторы сдвига. Можно будет явно указать, требуется ли логический, арифметический, или циклический сдвиг. А кроме того сдвигаемый аргумент может быть с любой стороны. Плюс экзотические циклы в количестве даже не 4-х, а 7-ми видов. А аспектно-ориентированное программирование - это так, желательный довесок ко всему остальному. Плюс комбинированная двоично-троичная логика.


Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 17:16

  



вы серьезно думаете, что это должно быть на уровне языка?


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

Вот пример на php, надеюсь понятный
http://ideone.com/nYzpa3

А Вы в серьёз считаете, что тип ternary logical, в котором (!true)!=(false) следует написать на языке, в который из логических типов встроен только boolean?

Добавлено @ 17:58
А что такое контракт?


Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 18:00

контракт есть договор, соглашение. например использование любых свойств параметра шаблона в C++ есть контракт (если в шаблон подставить нечто, не имеющее этих свойств, не скомпилица)

Добавлено через 1 минуту и 52 секунды
а по первому - я и на bool не настаиваю, весчь избыточная (в языке, различающем типы сдвигов ) 

Не понятно.
Да речь не о том. как он будет назван. Речь о том, что в  будет вести себя различно в зависимости от типа: если f объявлена как чисто двоичная переменная, то гарантируется выполнение хотя бы одной ветви, а если как эмулирующая троичную, то возможно не выполнение ни одной из ветвей при значении null. Кстати, null не будет нолём. Если предполагается логическое значение, то null будет третьей логической константой, а если предполагается указатель, то тот же null означает пустой указатель. Если же существует неоднозначность, то null_ptr - полумера, так как означает пустоту любого указательного типа. На mmz же можно будет написать null as ternary logical и неоднозначность решена без каких либо операций, этот null логический. В другом месте пишем  и этот же null уже означает пустой указатель на беззнаковое длинное целое. Причём, в отличие от (unsigned long int *) as - дирректива, а не оператор, так что эту конструкцию даже оптимизировать не надо, вызова оператора приведения в as pinteger просто нет.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 19:29

А ещё  и  будут вести себя различно, если тип переменной f эмулирует троичный тип, а если он чисто двоичный, то одинаково. При булевом f  означает "пока ", а  - "пока ", но !true - это и есть false. Но в троично-логическом типе (f==true)!=(f!=false) и (f!=true)!=(f==false), при   означает "пока ". Если f равна true, то оба цикла, если f равна false, то оба цикла завершаются, но если f равна null, то  завершается, а продолжается.

Добавлено через 5 минут и 12 секунд
Не вижу ни смыла описывать такое поведение на каком либо языке, кроме языка реализации транслятора, ни возможности описать его на каком либо языке, кроме языка реализации транслятора. Вообще не вижу ни смыла описывать такое поведение, как часть самой программы, где оно будет наблюдаться, ни возможности описать такое поведение, как часть самой программы, где оно будет наблюдаться. Если же, например, c++ выступает в ипостаси языка реализации транслятора, то вот здесь то как раз не вижу, что может помешать эмулировать троичную логику.

вот, нашел книжку
http://www.ozon.ru/context/detail/id/2896278/

и для общего развития
http://www.ozon.ru/context/detail/id/5542451/