Собственно речь о такой вот штуке
Вещь конечно очень интересная и перспективная... но вот прикладное применение не выходит за рамки "Привет мир"...

Кто для чего использует это НоуХау?

Ну вот например, человек всё подробно расписал.

А что "человек расписал"?
Как с ними работать? Так это и в хелпе написано... описано чисто гипотетическое использование для некой абстрактной задачи...
Вопрос то "Практическое применение", полезность, незаменимость и тд.

навскидку:
1) ORM с Code First - без атрибутов пришлось бы голову ломать над маппингом типов и заданием констрейнтов (NOT NULL, PK, FK  и т.д.), а так всё просто
2) сериализация, (своя, кастомная) - очень просто задать, что конкретное published свойство не нужно сериализовать, а конкретное не published - нужно, + прочие тонкости
3) юнит-тестирование: указать, тестить ли этот класс и как 
4) допустим, переменные/свойства будет менять пользовательский скрипт - тогда легко навесить дополнительные ограничения, допустим, задать размерность или единицы измерения, и код исполнения скрипта сможет делать проверки по типу "не складываются ли метры с килограммами или дюймами и не присваивается ли разные размерности/единицы друг другу"
5) статическое конфигурирование программы (без конфигурационных файлов/реестра), более гибкое, чем {$IFDEF ...} 
6) прочее: может оказаться полезным в иных плагинных системах, кодогенераторах, системах статического анализа кода

в общем - ничего "незаменимого", только упрощение некоторых довольно редких и специфических задач
и - "если вы задаёте такой вопрос, значит, ВАМ оно (пока) не нужно!"

Ещё как минимум:
7) Помощь для IDE для подсветки
8) Валидация на поля
9) Помечать классы или методы для их вызова, регистрации в фреймворках (не только ORM)
В общем вещь очень удобная и нужная, жаль, что так поздно о ней в делфи вспоминают, а лямбды видимо и вообще через 10 лет сделают

анонимные методы не устраивают?

я тоже за лябмды. они намного лаконичней

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

Можно пример из жизни? 

Да, тут не поспоришь. Как по мне это единственное "практическое" применение. Имеется ввиду для целевого функционала, а не для отладок и танцев.

Не уверен, что эта задача именно для Delphi актуальна, куда проще тут перегрузку операторов использовать

Если можно подробнее. точнее "Чем лучше {$IFDEF ...}?". Как по мне это принципиально разные механизмы как по задачам так и по результату работы.


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

пример ORM? .NET Entity Framework
дельфисты пока еще только начинают подтягиваться - http://www.devart.com/entitydac/
старые дельфовские ORMки - наверняка без использования атрибутов, есть ли в них code first - не знаю
Illusion Dolphin     правильно вспомнил валидацию (проверку на допустимость значений свойств объектов при их вводе)
правильно, отсюда и определенные преимущества одного над другим и наоборот

в целом, функциональность атрибутов почти такая же, как и у констант, но 1) в дельфях константу можно как-то "привязать" к классу или к полю/свойству, только вручную дав ей имя типа "TMyClass_MyProperty_MyAttribute" - и её значение в коде получишь, только используя этот идентификатор полностью, а наличие/значение атрибута можно проверить/получить, имея отдельно имена класса, свойства и атрибута - например, перебирая в цикле свойства класса произвольного объекта и 2) константу нельзя проверить на наличие/отсутствие - если где-то есть к ней доступ, то где-то она должна быть определена, атрибут же можно просто не задавать - в этом сходство с {$IFDEF}

Это сообщение отредактировал(а) PointerToNil - 22.7.2014, 19:28

Шутить изволитес? Пример того как без этого ну прям ни как... 


Нуда, нуда, все в курсе. Давайте не уходить от темы. 
Вы объясните как для танкистов, если конечно не тяжело. Типа вот три строчки при использования атрибутов и вот так без них. и сразу видно что атрибуты рулят. 

вот эта тема тоже на уровне лозунга... да и 

вводе кем? Может при присвоении значений? А в чем выгода?


в целом функциональность кнопки унитаза "почти такая же, как и у" любой другой кнопки.
Может функционально атрибут есть не что иное как class, ссылающийся на некоторое поле в RTTI структуре другого класса?
 

наверно самый удачный способ построения приложений... если на каждое изменение перебирать, то наверно станет вопрос о том, что это приложение делает  А я то наивный не как не мог понять, что ж так тормозит то софт... а он "перебирает"...


  
Давай, бомби дальше.

Добавлено через 3 минуты и 35 секунд

Вообще думаю Вам стоит создать тему "о сходстве TAttribute с {$IFDEF}" и это будет   
Разумеется кратко изложить сходства и различия в первом посте.

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

Точно также как делфи обходится без лямбд - можно обходиться и без атрибутов, интерфейсов, и чего тут таить, даже без классов. Да и циклы можно исключить, ведь есть goto (JMP в конце концов). А то что без этого можно обходиться никак не уменьшает тех возможностей, которые данные технологии привносят в языки.  Если вам они не нравятся - забудьте про них, пока совсем не припрёт и будет необходимо это освоить. Если надо разобраться уже сейчас, что с этим делают уже много лет другие - я могу посоветовать поискать что-то вроде с# using attributes и взглянуть на готовую экосистему с атрибутами. 

P.S. Давайте не будем вдаваться в скептицизм, ведь если это многие используют - значит зачем-то это уж точно надо ;)
P.P.S. drkot, Если хотите - могу прокомментировать по каждому вашему пункту.

необходимости конечно нет, но есть ситуации в которых их применение облегчает и упрощает подход и разумное использование целесообразно.

Ответ, это не всегда конкретный набор букв, зачастую это процесс. Если Вы обратите внимание на формулировку вопроса, то наверняка заметите, что вопрос открытый, и широкий. Наверняка Вам приходилось писать сочинение на тему "Как я провел лето?". Так вот это вопросы одной категории.
Если бы меня интересовало "Как использовать" или "как применить к..." то вопрос был бы сформулирован именно так, но меня интересуют сферы практического применения, и именно практического, а не теоретические книжные изыскания "о том как люминесцентная ручка молотка упрощает процесс забивания гвоздей".
Пока что реальная полезность обнаружена только при работе с файлами имеющими "человеко читаемую" структуру. И ради простоты масштабирования и изменения этой структуры можно пойти на "жертвы" в быстродействии. 

Убеждением занимаются компетентные органы ;) и смысла в этом действительно мало. А Вы пока что даже не удосужились аргументировать свои лозунги, а вот это уже пионерство...
Если бы Вы показали как решается та или иная задача и это оказалось бы полезно, то и убеждать бы никого не понадобилось.
А пока что Вы только провели параллель между объектной моделью скоппелированной программы и препроцессором исходного кода. 

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


да вот посмотрел на неё, и решил тему запостить. Особенно озадачило использование атрибутов для описания внешних функций (закрадывается мысль, что не найдя никакой более внятной задачи для атрибутов решили приспособить эту, типа чтоб не нарушать маркетинговой линии. причем умудрились переписать все стандартные примеры для VS), очень сильно напомнило перекрашивание роз... А все остальное носит чисто гипотетическое применение и начинается со слов "... когда Вы высадились на Марс ..." и дальше идет описание задачи где полезны атрибуты.

Когда речь идет о классах, интерфейсах и прочих структурах языков высокого уровня, то их применение как минимум понятно с практической точки зрения (хотя и не обязательно).
Разве что упомянутые лямбды (рожденные к стати в скриптовых языках, и по воле маркетологов навязанные нативным) не имеют заметного практического значения. А в идеологии OP они и не уместны вовсе. 
а если исходить из

то и книжки про пи...сов и порно на каждой странице "точно нужно", его ведь ого го сколько...


нет, так подробно не надо. Достаточно развить тему 

интересно звучит, хотелось бы узнать больше.

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

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