Чем больше имею дело с Delphi, тем лучше вспоминаю, что мне так нравилось в Аде. Хит сезона: в Delphi файл считается принадлежащим проекту (отображается в IDE), если в dpr написано uses ... in '....pas'. IDE при этом отсчитывает путь от файла проекта, но если компилировать с командной строки, то модуль ищется относительно текущей директории, причём, search path игнорируется напрочь. Забавно, компилятор устраивает наличие .dcu в search path, но .pas ищется только относительно текущей директории. Этот GUI-CLI псевдодуализм всплывает не по отдельности, а в комплекте с ещё одним: группа проектов, созданная в IDE, по синтаксису является makefile, и, действительно, можно запустить make -B -f MyProjectGroup.bpg, и группа проектов скомпилируется, но только до тех пор, пока все проекты в той же директории, что и группа проектов. Ах, да, чуть не забыл, есть же ещё такая штука как .res файлы, которая генерится и компилируется IDE неявно и автоматически. Казалось бы, проблему можно решить, создав в явном виде .rc файлы. Проект Delphi может содержать не только .pas файлы, но и .rc файлы (.pas и .rc — это всё, что может быть в .dpr). IDE отображает .rc файлы как относящиеся к проекту, если они подключаются {$R '....res' in '....rc'}, и собирает их автоматически. Однако, dcc32 так не умеет. Совсем. На этот раз ему нужен только .res, и как–то по–простому впилить компиляцию ресурса, чтоб работало и из make, и из IDE, если открыть группу проектов, уже не получается. Заколебал этот псевдодуализм, когда IDE и консольные утилиты работают с одними и теми же форматами, но очень по–разному. Ах, да, не забыть .dof для IDE и .cfg для компилятора с этим их синхронным редактированием. А как в Аде? Есть GNAT Project с расширением .grp. GPS (GNAT Programming Studio), gnatmake и gprmake все работают с одним и тем же форматом, и ведут себя одинаково. Компилятор знает, какие модули в проекте. IDE тоже это знает, и информация поступает из одного места по одному и тому же алгоритму. А ещё вместо того, чтобы в настройках проекта пихать в search path для модулей и объектных файлов конкатенацию путей до всех зависимостей, можно из одного проекта подключить другой проект. Добавление зависимости, удаление зависимости — всё произойдёт в одном месте, и и компилятор, и IDE поймут это одинаково. В Delphi что–то похожее есть только для runtime packages.

http://delphitools.info/dwscript/ DelphiWebScript > Scripts can be executed from Delphi applications (in a safe, sandboxed fashion) > Optional JavaScript code generation (compile to JavaScript)

Generics хреново сочетаюся с отсутствием нормального RAII, но, наверное, в Embarcadero думают иначе. Предположим, нас интересует арифметика только с операторами +, -, *. Представим себе, что у нас, помимо Integer, есть модуль длинной целочисленной арифметики. Далее, есть generic, который на вход берёт целочисленный тип, а на выходе даёт рациональные числа из них. Либо для вещественных чисел можно взять Double. Далее, есть generic, который на вход берёт тип вещественных чисел, а на выходе даёт комплексные числа из них. Далее, есть generic, который на вход берёт некий числовой тип и делает из него матрицы. Проверить, нормальные ли generics в языке программирования, довольно просто: все возможные осмысленные комбинации этих generic'ов должны быть рабочими, и написание каждого из этих модулей не должно быть утомительным обходом языковых ограничений. Впрочем, в Delphi их хотя бы возможно обойти. Во Free Pascal generics последний раз, когда я смотрел спецификацию, никуда не годятся, потому что нет RAII. Никогда не понимал ФриПаскалистов. Скопировали Delphi 7, а дальше не стали. Испортили язык фичами из C++, но так же хорошо, как в C++, они не могут работать. Про Аду и знать не хотят.

В Delphi XE2 так и не сделали человеческий, блин, RAII, с контролем над инициализацией (Interface и Variant инициализируются nil, нельзя вызвать метод, пока переменная не инициализирована; у record есть деструкторы, но нет конструкторов) и копированием (у Interface инкрементируется счётчик ссылок, не всегда то, что нужно), и это всё несмотря на то, что в RTL всё необходимое давно есть! Лечится, допустим, оборачиванием interface в record с методами. Методы record сначала проверят, а не nil ли интерфейсное поле, инициализируют при необходимости. Далее, если метод собрался что–то менять, можно сделать Copy On Write. И только после этого передавать вызов интерфейсному объекту. Прям хоть модули для m4 пиши, чтоб одно и то же не копипастить вручную. Несмотря на это, Delphi нельзя назвать застойным. В нём–таки сделана поддержка Unicode, COFF OBJ, Win64, всего того, что очень долго ждали.

DCCOSX.EXE

Давно я не следил за Delphi. А тем временем появились интересные статейки про RTTI в Delphi 7: http://hallvards.blogspot.com/search/label/RTTI (начиная со второй страницы) http://www.transl-gunsmoker.ru/search/label/RTTI (перевод) http://cc.embarcadero.com/item.aspx?id=24074 (готовые модули) В Delphi 7 RTTI весьма разрозненно реализован. Самое простое — это свойства, их мы находим в TypInfo.pas. Далее, чтобы загрузка формы из ресурса могла работать, нужно находить published поля. Это мы находим где–то в Classes, в реализации, без публичного интерфейса. Наконец, самое сложное — published методы. Чтобы при загрузке формы из ресурса можно было назначать методы, адрес published метода можно искать по имени, но и только–то. Перечисление методов — опять лезть во внутренности, не имея публичных интерфейсов. При этом сигнатуры published методов недоступны. Если читать блог по порядку, то сначала автор конструирует самодекомпилятор для методов, перечисляя событийные свойства и используя сигнатуры событийных свойств. Если метод не назначен ни на какое событие, сигнатура недоступна. Далее автору, видимо, подсказали про модуль ObjAuto и директиву $METHODINFO, и на этот раз рефлексия сделана без хаков. После 7й Delphi RTTI был существенно расширен в Delphi 2010. Появился модуль Rtti.pas, где всё приподнесено на блюдечке. Так даже неинтересно.