Почему я должен заботиться о RTTI в Delphi?

Большинство людей, вероятно, не будут использовать его в реальном мире.

Люди, которые будут использовать это, являются строителями фреймворка. Такие структуры, как DUnit, широко используют RTTI.

С новыми возможностями RTTI мы должны ожидать появления более продвинутых фреймворков и инструментов, похожих на то, что доступно для .NET. Эти рамки революционизируют ваше развитие выше, чем RTTI будет на нем.

D2010 расширенный RTTI очень похож на отражение С#. Это дает вам возможность попасть в любое поле объекта или проверить его методы. Это имеет всевозможные потенциальные возможности. Например, если вы можете прочитать любое поле объекта, вы можете написать код сериализации, который может работать с любым объектом. И возможность проверки методов и получения их имени и подписи делает класс намного легче зарегистрировать в механизме сценариев.

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

RTTI в Delphi всегда был важным с версии 1.0. Классические функции RTTI включают раздел "опубликованные" свойства классов, который позволяет функциям Object Inspector и компонентному дизайну компонентов работать. Для моих целей я часто использовал опубликованные свойства класса, чтобы разрешить перечисление этих свойств во время выполнения. Чтобы сохранить вещи из моих объектов на диск, для сохранения.

Delphi 2010 RTTI расширяет этот классический RTTI массово, настолько, что вас можно простить за то, что у Delphi даже не было RTTI до delphi 2010.

Я бы сказал, что # 1 наиболее полезные приложения из "The New RTTI" (как уже упоминалось в нескольких других ответах) будут в ракурсах, написанных гуру, которые:

• Поддерживать сохранение файлов или баз данных. База данных и конфигурации, а также структуры и компоненты для сохранения и загрузки документов будут использовать это под капотом.

• Обработать травление/сортировку/кодирование/декодирование в различные и сверхпрочных форматов, таких как JSON, XML, EDI и т.д.

• Тестирование модулей было упомянуто кем-то другим (JUnit), но я думаю, что, возможно, одни и те же структуры могут быть очень полезны для инструментов отладки и отчетов об ошибках. Учитывая объект, переданный в качестве параметра, в стеке, почему бы не получить отчеты об ошибках, которые могут сбрасывать все данные, которые были переданы вместе с неработающей функцией, а не только список функций?

Как вы можете видеть, некоторые творческие люди, скорее всего, придумают для этого еще больше возможностей. Вы могли бы сказать, что, хотя он не привносит четность в отражение .NET(о чем еще говорит другой ответ), он привносит множество "динамических языков" (Think Perl, Python, JavaScript) в сильно сильно типизированную статическую мире системных решений Delphi.

Ищите TMS Aurelius, и вы увидите, что атрибуты RTTI очень полезны с точки зрения создания ORM DataBase Framework и XML Сериализации в чистые объекты и наоборот.

Для меня, лично, расширенный RTTI дал возможность получить вызов соглашения из указателя метода. Однако в настоящее время этот код находится под условной директивой, потому что я не удовлетворен этим.

(Критики и предложения по работе с базовым RTTI приветствуются, tho)

Вы должны заботиться, потому что они положили его на коробку. Ясно, что они думают, что некоторые люди будут заботиться.

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

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