Обновился Delphi RoadMap

← →
PEAKTOP © (2009-05-16 11:48) [0]

На блоге Марко Кэнту появился отчет о конференции Embarcadero об Delphi RaodMap

Из интересных новшевств:
1) компилятор для Win64
2) возрождение Kylix в виде проекта DelphiX для компиляции под LINUX и MacOS
3) ориентация на Windows7 и новые устройства ввода данных (например, TouchScreen)

В общем, читаем сами
http://blog.marcocantu.com/blog/delphi_live_2009_2_roadmap.html

← →
speller © (2009-05-16 12:33) [1]

Давно пора ) Только бы еще старые баги поправили )

← →
Рамиль © (2009-05-16 12:33) [2]

> компилятор для Win64

У меня такое чувство, что когда делфи научится компилировать под x64, уже появится x128.

← →
oxffff © (2009-05-16 12:49) [3]

> PEAKTOP © (16.05.09 11:48)

Самое интересное extended RTTI.

← →
Григорьев Антон © (2009-05-16 14:03) [4]

> PEAKTOP © (16.05.09 11:48)
> 2) возрождение Kylix в виде проекта DelphiX для компиляции
> под LINUX и MacOS

Ну вот, опять путаница будет. Имя DelphiX уже занято.

← →
oxffff © (2009-05-16 15:52) [5]

Можно еще здесь посмотреть картинки. Более информативно

http://robstechcorner.blogspot.com/2009/05/delphilive-pictures.html

← →
Pavia © (2009-05-16 16:09) [6]

> > компилятор для Win64У меня такое чувство, что когда делфи
> научится компилировать под x64, уже появится x128.

По плану в конце текущего года должны.Если планы неменяли.

← →
Кто б сомневался © (2009-05-16 16:38) [7]

> Давно пора ) Только бы еще старые баги поправили )

во - во. Баги хоть бы поправили. Из за некоторых трудно работать под 150% dpi, а в некоторых случаях даже нереально.

← →
Кто б сомневался © (2009-05-16 16:42) [8]

а это сейчас мода такая, пальцами тыкать на большом экране с презентацией? указки (втч и лазерные) уже не рулят?

← →
ZeroDivide © (2009-05-17 01:51) [9]

В целом, мне показалось, что новый Project Manager трезвый и ненакуренный. А именно из-за ошибок в проджект менеджменте, кастомеры с недоумением смотрели на все, что происходило с Delphi в последние годы.

Надежда есть. Я доволен. Думаю, сделают все что обещали, с учетом того что инвестиции в R&D по Delphi теперь в несколько раз больше. В общем, Delphi - forever, однозначно.

← →
Eraser © (2009-05-17 02:50) [10]

> В целом, мне показалось, что новый Project Manager трезвый
> и ненакуренный.

да уж! радует, что последние несколько лет свернули они на праведный путь, подальше от .net и прочих ECO )

← →
тимохов © (2009-05-17 12:31) [11]

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

← →
pasha_golub © (2009-05-17 17:49) [12]

> тимохов © (17.05.09 12:31) [11]

> аспекто-оринетированное программирование

Шо це?

← →
тимохов © (2009-05-17 19:22) [13]

2Павел.

Начни с этого http://ru.wikipedia.org/wiki/%D0%90%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Я перечитал, в общем-то близко к моему пониманию АОС.
Вопросы будут, спрашивай.

← →
T&F (2009-05-19 05:00) [14]

Планы конечно радуют, как минимум 25% должно быть реализовано уже в этом году (хочется надеяться)

* Delphi Weaver – основной целью которого является улучшение юзабилити IDE, поддержка командной разработки(интеграция с SVN), DataSnap с поддержкой http, поддержка touchscreen-ов, поддержка Firebird-a в DbExpress, Soap 1.2, поддержка Windows 7 и кое-что ещё. * Delphi “X” – кроссплатформенность(Linux + MacOs) * Project Chromium – Pascal Code Formatter, документация по OpenToolsApi, новая модель привязки к данным(не через датасеты), более тесная интеграция с БД-тулзами от Embarcadero. * Project Commodore – долгожданные 64-бита, поддержка многопоточности в RTL.

← →
tesseract © (2009-05-19 09:56) [15]

> 2) возрождение Kylix в виде проекта DelphiX для компиляции
> под LINUX и MacOS

Надеюсь будет получше, чем в Kylix. И для маков Cocoa сделают. А то LCL пока не слишком-то под Cocoa собирается, да и сам лазер не фонтан.

← →
pasha_golub © (2009-05-19 16:44) [16]

> Я перечитал, в общем-то близко к моему пониманию АОС.

Херь какая-то. На кошках есть пример?

← →
Тимохов_ (2009-05-19 17:00) [17]

2Павел

Вот статья вроде неплохая.
http://www.ibm.com/developerworks/ru/library/pollice/index.html
Их много в интернете.

Цитата оттуда:
Аспекты - это пересекающиеся (crosscutting) отношения. Поэтому аспекты непросто инкапсулировать в отдельный класс. Кроме того, если строго следовать объектно-ориентированной парадигме, необходимо представить такие отношения в единой, удобной для сопровождения форме.

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

← →
test © (2009-05-19 17:02) [18]

тимохов © (17.05.09 19:22) [13]
Ссылки на книги есть?

← →
Юрий Зотов © (2009-05-19 17:06) [19]

> pasha_golub © (19.05.09 16:44) [16]

> На кошках есть пример?

Есть.

Пусть имеется здоровенная программа, работающая с БД. В ней куча классов, которые пишут данные в кучу таблиц. Все отлажено, все работает, но в один прекрасный день потребовалось ввсти логирование - что, куда и когда было в БД записано.

Что делать? Перекапывать здоровенные исходники и добавлять в кучу мест запись в лог? Это долго и чревато ошибками (что-нибудь обязательно будет упущено).

Пусть, к примеру, мы знаем, что реальные изменения в БД вносит метод Exec класса TQuery. Можно было бы переписать только его (добавив логирование), но портить генофонд не имеем права. Тогда используем АОП.

Пишем еще один класс и некий дескриптор к нему. Смысл этого действа заключается в том, что теперь, когда бы и откуда бы ни был вызван метод TQuery.Exec, этот вызов будет перехвачен и управление попадет в заранее определенный метод X нашего нового класса, а уж из этого метода X мы можем вызвать метод TQuery.Exec.

Поэтому добавляем в наш метод X ведение лога - и задача решена.

← →
Тимохов_ (2009-05-19 17:15) [20]

2Павел. На пальцах.

Самый стандартный пример - это проверка прав доступа и логирование.

Вот представь, что у тебя есть программа в которой есть много-много методов, в которых нужно проверять права доступа, а в конце писать в лог. Каждый из этих методов состоит (допустим) из трех кусков:

1. Проверка прав.
2. Бизнес-логика.
3. Логирование.

1 и 3 - это паразиты, которые есть в каждом методе и которые есно, хочется обобщить и автоматизировать - т.е. чтобы они по факту были, но чтобы не болела голова об их добавлении в код.

Для подобного рода обобщений есть масса методологий. Например, можно методы засунуть в супер-класс, в нем сделать виртуальные методы для бизне-логики, а п.п. 1 и 3 вызывать в супер-классе. Можно еще как-то.

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

Например (это только пример!) в Delphi код может выглядеть так:

{$method_type "business"} procedure PayMoney(...); begin // только бизнес-логика end;

при этом где-то для типа "business" описано, что нужно добавлять в конец и начало метода.

Текущие реализации есть в Java. Вроде JAspect называется штука.

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

АОП можно рассматривать шире, не только как указание компилятору (это, согласись, детали реализации). Как и ООП АОП - это философия классификации исходного кода в целях его дальнейшего повтороного использования. Причем АОП не исключает ООП (последний, всяко мощней), но однозначно имеет свое применение в определенной ситуации.

← →
Sergey Masloff (2009-05-19 17:23) [21]

Тимохов_
Эта фигня (не в плохом смысле) была известна задолго до придумавания слов АОП ;-)
А вот с отладкой этого дела проблемы не возникают?

← →
tesseract © (2009-05-19 17:42) [22]

> Смысл этого действа заключается в том, что теперь, когда
> бы и откуда бы ни был вызван метод TQuery.Exec, этот вызов
> будет перехвачен и управление попадет в заранее определенный
> метод X нашего нового класса, а уж из этого метода X мы
> можем вызвать метод TQuery.Exec.

Шуточки Smalltalk / Objective-C лохматых годов ?

← →
Тимохов_ (2009-05-19 17:43) [23]

2Сергей.

Сам понимаешь, что программируя на дельфи я не могу давать директивы компилятору, какие аспекты куда вставлять, ибо таких директив таких пока нет.

У меня есть свое преломление данной методологии. В моем представлении АОП проблем с отладкой нет. Даже есть достоинства.

Если интересно, то могу поделиться своим подходом.

Представь, что есть некий самописный фреймворк для работы с БД в объектом стиле. Т.е. в памяти объекты, на диске реляционка. Фреймворк берет на себя все проблемы с мепингом, транзакциями и пр. Не сказать, что очень это производительно, но для задач построения систем бух. и фин. учета вполне хватает.

Объекты имеют супер-класс. В нем есть виртуальные методы: после_создания, перед_сохранением, после_ввода_значения и т.д. - штук 20.

Для прописывания конкретной логики я наследую от супер-класса, переопределяю нужные события и т.д.

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

В результате искания в интернете (где-то 2005 год) я нашел АОП. Мне очень понравилась идеология разделения макаронного кода на аспекты (темы, точки зрения, как угодно :) ). В итоге я реализовал технологию, при которой каждому классу можно было приписывать один или более спец. классов, которых я назвал аспектами. Эти классы реализуют одну конкретную тему - будь то безопасность, или реализация конкретного бизнес-правила.

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

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

← →
Игорь Шевченко © (2009-05-19 19:54) [24]

А в C++ примерно тем же самым занимается множественное наследование...На которое так долго ругались программисты на Паскале. Ан нет, идея-то жива, только очередные яйцеголовые ее по-другому обозвали - точки зрения там всякие и прочее словофлудие.

← →
jack128_ (2009-05-19 22:29) [25]

> {$method_type "business"}
> procedure PayMoney(...);
> begin
> // только бизнес-логика
> end;

насколько я понимаю технически такие вещи можно реализовать макросами LISP"а или например Nemerle. Но в дельфи таких возможностей нет и не будет. Если CodeGear дженереки не осилил, то о таких продвинутых фишках можно и не мечтать.

← →
jack128_ (2009-05-19 22:40) [26]

2 Тимохов
> Ан нет, идея-то жива, только очередные яйцеголовые ее по-
> другому обозвали - точки зрения там всякие и прочее словофлудие.
>

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

← →
DVM © (2009-05-19 22:42) [27]

> Юрий Зотов © (19.05.09 17:06) [19]

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

← →
тимохов © (2009-05-19 22:43) [28]

2Женя

Я так понимаю, что Игорь говорил про мою интерпретацию АОП, а не про исходные примеры. В целом я с ним согласен. АОП и его интерпретации не панацея, а одна из методологий.

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

← →
Игорь Шевченко © (2009-05-19 22:46) [29]

jack128_ (19.05.09 22:40) [26]

Ты наверное ко мне хотел обратиться ? :)

Как в Turbo Vision на C++, где классы с какого-то момента в иерархии обладают свойством сериализации себя - подмешивается дополнительный предок, который умеет сериализовать.

Не думаешь же ты, что написание какого-то атрибута перед методом класса волшебным образом изменяет его поведение во всех языках программирования (насколько я слышал, в Java для этого изменяется byte-код)

На мой взгляд - это еще одна разновидность множественного наследования, только обозванная аспектно-ориентированным программированием.

← →
Игорь Шевченко © (2009-05-19 22:50) [30]

тимохов © (19.05.09 22:43) [28]

> Я так понимаю, что Игорь говорил про мою интерпретацию АОП,
> а не про исходные примеры

А иначе как сделать ? Механизм остается один - внедряется набор дополнительных функций, вероятно, еще одна таблица виртуальных методов, исправляется основная таблица, чтобы ее вызовы перенаправлялись во вновь созданную, там вокруг основных вызовов делаются обертки (before/after) - и вуаля.

Если ты это делал вручную, то понимаешь, насколько это выглядит в исходном коде.

← →
Eraser © (2009-05-20 02:22) [31]

> [19] Юрий Зотов © (19.05.09 17:06)

хелперы, отчасти, решают эту проблему.

← →
Псалтырь © (2009-05-20 08:25) [32]

> Игорь Шевченко © (19.05.09 19:54) [24]
>
> А в C++ примерно тем же самым занимается множественное наследование.
> ..На которое так долго ругались программисты на Паскале.
> Ан нет, идея-то жива, только очередные яйцеголовые ее по-
> другому обозвали - точки зрения там всякие и прочее словофлудие.
>

+100

← →
test © (2009-05-20 08:49) [33]

Игорь Шевченко © (19.05.09 22:46) [29]
А как же конечные автоматы? Там выставление состояний может менять поведение.

← →
jack128_ (2009-05-20 10:05) [34]

2 Игорь
> Ты наверное ко мне хотел обратиться ? :)

Да такие философские темы идут, пока пост пишешь мысль так далеко ускачет, что забудешь с чего начинал и кому хотел ответить :-)

> Как в Turbo Vision на C++, где классы с какого-то момента
> в иерархии обладают свойством сериализации себя - подмешивается
> дополнительный предок, который умеет сериализовать.

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

> Не думаешь же ты, что написание какого-то атрибута перед
> методом класса волшебным образом изменяет его поведение
> во всех языках программирования (насколько я слышал, в Java
> для этого изменяется byte-код)

Зависит от языка. В Java - не знаю, что там намутили, а например в Nemerle макросы - это процедуры, которые на вход получают AST и могут менять его. То есть банально вставить в в начало каждого метода, помечанного конкретным атрибутом, код: Log.Write("<<<< " + AST.CurrentMethodName);

> Eraser © (20.05.09 02:22) [31]
>
> > [19] Юрий Зотов © (19.05.09 17:06)
>
> хелперы, отчасти, решают эту проблему.

Хм. Единственный вариант с хелпером, который я вижу - это реализовать TQueryHelper.Exec и подключить модуль с этим хелпером в каждый модуль проэкта. Но это решение - суть макроподстановка. Некрасиво.. Или у тя другой вариант решения?

← →
Игорь Шевченко © (2009-05-20 10:52) [35]

test © (20.05.09 08:49) [33]

> А как же конечные автоматы? Там выставление состояний может
> менять поведение.

Также, как конечные пулеметы

jack128_ (20.05.09 10:05) [34]

> а например в Nemerle макросы - это процедуры, которые на
> вход получают AST и могут менять его

Афигеть. То есть, программист пишет одно, а потом легким движением руки код превращается в вовсе не то, что кодом хотели сказать.

Удачи в сопровождении:)

← →
Petr V. Abramov © (2009-05-20 11:12) [36]

> новая модель привязки к данным(не через датасеты)

а через, пардон, что?

← →
Polevi © (2009-05-20 11:27) [37]

>Игорь Шевченко © (20.05.09 10:52) [35]

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

[Transactional]
[Log]
[CheckPermission]
public void ChangeDocumentState(int id)
{
//business logic
}

такого эффекта невозможно достичь существующими средствами языка

← →
Игорь Шевченко © (2009-05-20 11:30) [38]

Polevi © (20.05.09 11:27) [37]

> такого эффекта невозможно достичь существующими средствами
> языка

Пардон, какого языка ?

← →
Polevi © (2009-05-20 11:35) [39]

Delphi, C#

← →
Polevi © (2009-05-20 11:37) [40]

вот еще пример - кеширование вызовов метода

[Cachable]
public string SelectSomeData(int p1, int p2)
{
...
}

много можно придумать полезного...

← →
Polevi © (2009-05-20 11:40) [41]

если кому интересно, рекомендую http://www.postsharp.org/
там есть примеры

← →
test © (2009-05-20 11:49) [42]

Игорь Шевченко © (20.05.09 10:52) [35]
Про пулеметы не слышал поищу на досуге.

http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D1%8B%D0%B9_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82
Конечный автомат — в теории алгоритмов математическая абстракция, позволяющая описывать пути изменения состояния объекта в зависимости от его текущего состояния и входных данных, при условии что общее возможное количество состояний конечно. Конечный автомат является частным случаем абстрактного автомата.

Многие с ним уже сталкивались, регулярные выражения(разбор текста) это как раз конечный автомат применительно к тексту. В игре Fear если я не ошибаюсь на конечных автоматах построена логика поведения врагов(обычных салдат а не босов).

← →
Polevi © (2009-05-20 11:49) [43]

чтото меня проперло.. :)

например в Java есть ключевое слово seriallizable
public serializable void SomeMethod() - VM гарантирует что только один поток одновременно сможет выполнять этот метод

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

[Serializable]
public void SomeMethod()
{
...
}

← →
Юрий Зотов © (2009-05-20 11:51) [44]

> test © (20.05.09 11:49) [42]

А логика поведения боссов построена на бесконечных автоматах.

Все как в жизни...
:o)

← →
Palladin © (2009-05-20 11:54) [45]

> например в Java есть ключевое слово seriallizable

ээ.. я дико извиняюсь, а не synchronize ?

← →
test © (2009-05-20 11:55) [46]

Юрий Зотов © (20.05.09 11:51) [44]
Нет босы на обычной логике и тупые, только живучие очень.

1 Искать пока не найдеш
2 нашел
3 стрелять
4 пункт 1

Инфузория туфелька во всем своем великолепии ))

← →
Polevi © (2009-05-20 12:09) [47]

>Palladin © (20.05.09 11:54) [45]
да возможно, давно не писал на Java

← →
Юрий Зотов © (2009-05-20 12:26) [48]

synchronized

← →
Jack128_ (2009-05-20 13:24) [49]

>
> Удачи в сопровождении:)

Ну я не пишу на этих языках.

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

> Polevi ©
Nemerle, Nemerle, Nemerle.. Все твои примеры на раз два реализуются на этом языке..

← →
Jack128_ (2009-05-20 13:40) [50]

> если кому интересно, рекомендую http://www.postsharp.org/

Хе. Прикольно

> Polevi © (20.05.09 11:27) [37]
> >Игорь Шевченко © (20.05.09 10:52) [35]
>
> АОП и множественное наследование пересекаются только в случае
> implemetation injection.. когда хочется наделить объект
> уже готовой реализацией интерфейса. Но АОП на этом не заканчивается,
> достоинства его в декларативности, например заставляем
> метод работать в транзакции, проверяем права доступа и при
> этом ведем лог
>
> [Transactional]
> [Log]
> [CheckPermission]
> public void ChangeDocumentState(int id)
> {
> //business logic
> }
>
> такого эффекта невозможно достичь существующими средствами
> языка

Это не правда.

>Jack128_ (20.05.09 13:24) [49]
>Nemerle, Nemerle, Nemerle.. Все твои примеры на раз два реализуются на этом языке..

возможно, но это не мейнстрим а надстройка над ним.. так же как и postsharp

А как компилятор должен поступить со словечками, которые в квадратных скобульках? подставить реализацию? Откуда взять? А если реализация зависит от контекста вызова? Вообщем, во что превращается

[Transactional]
[Log]
[CheckPermission]
function Tralala

в итоге?

Простите, если туплю :)

в скобульках названия классов-аспектов
если рассматривать реализацию АОП на примере пост шарп - то эта библиотека получает управление после сборки проекта, анализирует атрибуты, ищет в них классы-наследники своих типов и модифицирует IL-код, обрамляяя его вызовами или вообще заменяя реализацию (поведение будет зависеть от типа атрибута)

пример

[Serializable]
public sealed class Synchronized : PostSharp.Laos.OnMethodBoundaryAspect
{
public override void OnEntry(PostSharp.Laos.MethodExecutionEventArgs eventArgs)
{
//enter crytical section
}

public override void OnExit(PostSharp.Laos.MethodExecutionEventArgs eventArgs)
{
//exit crytical section
}
}

вызов любого метода помеченного атрибутом [Synchronized] PostSharp обернет примерно так

OnEntry()
try
{
SomeMethod();
}
finally
{
OnExit();
}

а контекст вызова - имя метода, типа, список значений параметров и тд доступны из PostSharp.Laos.MethodExecutionEventArgs eventArgs, то есть реализация аспекта может зависеть от контекста

← →
Jack128_ (2009-05-20 14:15) [57]

> pasha_golub © (20.05.09 13:52) [54]

конкретно в шарпе - компилятор создает экземпляры клоассов TransactionalAttribute/LogAttribute/CheckPermissionAttribute стримит их в генерируемый exe.
Соответственно в exe"шнике где то должен быть код, который смотрит какие аттрибуты связаны с конкретным методом и что то делать.

то есть сам компилер шарпа не изменяет метод ChangeDocumentState, чтобы добавить логирование.

Насколько я понял - Пост шарп работает после компилера C# смотрит для каких методов заданы какие атрибуты и соответственно меняет тело этих методов.

Polevi © (20.05.09 11:35) [39]

> Delphi, C#

Если не секрет, каким образом добавление атрибутов в Delphi позволяет менять поведение классов ?

>Игорь Шевченко © (20.05.09 14:20) [58]
а в Delphi уже есть атрибуты ?
Атрибуты это метаданные. Поведение может меняться при их анализе (компилятором или библиотекой)
Я могу написать код который будет анализировать RTTI типа и делать то или иное в зависимости от того что он там найдет.

Polevi © (20.05.09 14:27) [59]

Извини, прочитал слово "невозможно" в посте [37], как "возможно" :)

пост [58] прошу считать за срабатывание генератора случайных мыслей

Извините за офтопик.

Это одна из самых замечательных веток, виденных мною на этом форуме за последние года 2.

Спасибо всем, прежде всего за стиль общения. :))

"Какое наслаждение - уважать людей"
А.П. Чехов.
:))

> Polevi © (20.05.09 13:44) [53]
> >oxffff © (20.05.09 13:41) [51]
> очень содержательно, продолжение будет или еще не придумали
> ?

У меня есть идеи как это сделать. Но желания показывать нет. :)

Вкраце
Если делегирование на входе и выходе худо, бедно решается.
И даже можно будет намутить что то вроде задания в сравнимом синтаксисе
(прикрутив сюда анонимные методы)
[Serializable]
public sealed class Synchronized : PostSharp.Laos.OnMethodBoundaryAspect
{
public

То вот с универсальной передачей параметров вызова делагату реализатору чуть сложнее, но тоже решается. Рекомендую обратиться к TInvokeableVariantType.
Да вызов будет через variant. Однако заполучить контекст вызова мы можем. И компилятор сделает их метаописание за нас.
и соответственно передать их в класс аспект.

procedure DispInvoke(Dest: PVarData; const Source: TVarData;
CallDesc: PCallDesc; Params: Pointer); override;
Будет вам аналог PostSharp.Laos.MethodExecutionEventArgs

Единственное с чем я не согласен, так это ваша категоричность,
что этого сделать нельзя. Можно.

>oxffff © (20.05.09 19:07) [62]
я знаю что такое IDispatch, и в курсе что перехватив GetIdsOfNames и Invoke можно реализовать прокси. Но причем тут АОП, где декларативность ?
К тому же назвать это средствами языка можно с большой натяжкой.. Это скорее COM а не Delphi

> Polevi © (21.05.09 09:54) [64]
> >oxffff © (20.05.09 19:07) [62]
> я знаю что такое IDispatch, и в курсе что перехватив GetIdsOfNames
> и Invoke можно реализовать прокси. Но причем тут АОП, где
> декларативность ?
> К тому же назвать это средствами языка можно с большой натяжкой.
> . Это скорее COM а не Delphi

Я очень рад что вы знаете IDispatch.
Но он здесь не причем.
CustomVariant в руки + модуль objauto.
Декларативность очень простая.

Taspect=abstract class
Enter(CallDesc: PCallDesc; Params: Pointer); );virtual;abstract
Leave(CallDesc: PCallDesc; Params: Pointer); );virtual;abstract
end;

RegisterAspects(Tmytype,"MethodName",[Tsyncronyzed,TLogged,....]);

Обертка CustomVariant при вызове метода через objauto для типа вызывает

GetRegisteredAspectsForTypeMethod(Type:TClass;MethodName:string):Tlist<Taspect>

Далее мы можем run time добавлять, удалять aspects.

Декларативность вот
RegisterAspects(Tmytype,"MethodName",[Tsyncronyzed,TLogged,....]);

Idea By oxffff.

а CustomVariant не через IDispatch работает ? (нет делфи под рукой не могу посмотреть исходники)

>Декларативность вот
>RegisterAspects(Tmytype,"MethodName",[Tsyncronyzed,TLogged,....]);

ну если это назвать декларативностью..
впрочем если вы считаете что эта реализация "средствами языка" - ради бога
ООП можно и на ассемблере реализовать конечно.. ручками VTABLE формировать и прочее..

> Polevi © (21.05.09 11:08) [66]
> а CustomVariant не через IDispatch работает ? (нет делфи
> под рукой не могу посмотреть исходники)

Нет. Он работает параллельно.

procedure _DispInvoke(Dest: PVarData; const Source: TVarData;
CallDesc: PCallDesc; Params: Pointer); cdecl; var
LHandler: TCustomVariantType;
LDest: TVarData;
LDestPtr: PVarData;
begin
// dereference source
if Source.VType = varByRef or varVariant then
_DispInvoke(Dest, PVarData(Source.VPointer)^, CallDesc, Params)
else
begin

// figure out destination temp
if Dest = nil then
LDestPtr := nil
else
begin
VariantInit(LDest);
LDestPtr := @LDest;
end;

// attempt it
try

// we only do this if it is one of those special types
case Source.VType of
varDispatch,
varDispatch + varByRef,
varUnknown,
varUnknown + varByRef,
varAny:
if Assigned(VarDispProc) then
VarDispProc(PVariant(LDestPtr), Variant(Source), CallDesc, @Params);
else
// finally check to see if it is one of those custom types
if FindCustomVariantType(Source.VType, LHandler) then
LHandler.DispInvoke(LDestPtr, Source, CallDesc, @Params) else
VarInvalidOp;
end;
finally

// finish up with destination temp
if LDestPtr <> nil then
begin
_VarCopy(Dest^, LDestPtr^);
_VarClear(LDest);
end;
end;
end;
end;

> ну если это назвать декларативностью..

По другому это не назвать.

да называйте как хотите, все равно ваша реализация не попадает по определение "средствами языка", а именно это я оспаривал в [37]

> Polevi © (21.05.09 12:02) [68]
> да называйте как хотите, все равно ваша реализация не попадает
> по определение "средствами языка", а именно это я оспаривал
> в [37]

Ну да точно, я же это сделал сферическим конем в вакууме.

именно конем
при желании добавить аспект к методу необходимо найти все его вызовы и обернуть в CustomVariant или
написать его прокси-обертку который обернет вызов в CustomVariant
если бы это было "средством языка" этим бы компилятор занимался

Обновился Delphi RoadMap Найти похожие ветки