Обновился 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Женя

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

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

jack128_ (19.05.09 22:40) [26]

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

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

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

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

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

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

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

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

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

+100

← →
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 и подключить модуль с этим хелпером в каждый модуль проэкта. Но это решение - суть макроподстановка. Некрасиво.. Или у тя другой вариант решения?

test © (20.05.09 08:49) [33]

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

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

jack128_ (20.05.09 10:05) [34]

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

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

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

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

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

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

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

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

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

Polevi © (20.05.09 11:27) [37]

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

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

Delphi, C#

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

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

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

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