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

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

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

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

навскидку:
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 они и не уместны вовсе. 
а если исходить из

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


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

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

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

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

это не убеждение, это обоснование


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

PointerToNil, forum это "обсуждение" при переводе на русский. Это не "вопрос - ответ" в стиле "Stack Overflow". В ходе обсуждения идет обмен мнениями, и совсем не обязательно решается "сколько гвоздей нужно вбить на один погонный метр забора". Также обсуждение не предполагает обязательного принятия некоторой точки зрения всеми участниками и даже не предполагает изменение чьей бы то ни было точки зрения.

на вас кто то напал? Вас склоняют к принятию чьего то там мнения?
Или Вас просто попросили "аргументировать" свою точку зрения?

Моя позиция достаточно развернуто изложена, если в ней что то не понятно, или требуется пример кода, то надо так и писать.
А пока что Ваша позиция 

Собственно если это так, то не понятно зачем продолжать на ней настаивать? Она понятна, и не требует дальнейшего "убеждения". Не видите смысла - не делайте.


знаете, мне это напомнило фразу из одного старого кинофильма, времен моей наивной молодости. Там она звучала "... - даже у Даля нет". Не знаю скажет это Вам о чем то или нет... 


а почему? какая там специфика? 

раз она очевидна, то может ее (полезность) можно как то сформулировать? Скажем в рамках 20-30 слов хотя бы, чтоб очевидность стала очевидна и простым смертным?

PS: PointerToNil, Вы разницу между классом и директивой компилятора уловили?

PPS: не отправляйте тему в "религиозный войны" там одни маняки... там конструктива точно не будет...

вот иду по первой ссылке и вижу

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

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

Хочу нормальный пример! 

ну, ок, вот вам кусок кода из демонстрашки по EF 4.1
по этому описанию класса будет автоматически создана таблица в БД, каждому свойству будет соответствовать поле в ней
атрибутами можно указать: 
1) различия в наименовании классов/свойств и соответствующих им таблиц/полей БД
2) задать или конкретизировать тип (для строк - длину)
3) указать, что поле будет являться Primary Key, задать порядок колонок и т.д. и т.п.
4) указать, что свойство не соответствует никакому полю в БД
задавать атрибуты не обязательно, если устраивают соглашения мэппинга по умолчанию 
как это сделать без атрибутов - как уже говорил, "нужно голову ломать", поэтому альтернативного примера (как обойтись без атрибутов) у меня нет

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

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

ок, раз вам этот вопрос так не дает покоя, придется пояснить -
я имел в виду то, что и атрибуты, и константы, и  директивы МОГУТ выполнять  одну конкретную функцию - статическую конфигурацию программы - через жесткий выбор одного из произвольных фрагментов кода (с директивами) или же одной из веток if (с константами или атрибутами)
разумеется, выполняют эту функцию варианты совершенно по разному, тем не менее, результат будет одинаковый, по крайней мере с т.з. пользователя программы
различия вам должны быть ясны, а сходство результата все-таки попробуйте понять, если не получится - спрашивайте, поясню

Это сообщение отредактировал(а) PointerToNil - 24.7.2014, 02:51

PointerToNil,  однако, можете же конструктивно...
Пример хорош, отнести можно к сериализации. Так что пока из практического применения оставляем один пункт. Собственно как и было в начале.


если брать идеологию RTL (все таки форум по Delphi) то реализуется все на уровне конструкторов свойств (яркий пример DataSet). Ту нужно учесть что ни с С++ ни в С# идеология "конструирования" практически отсутствует и для реализации объекта новой структуры записи создается новый класс, а в Delphi используется используется базовый класс + настройки (созданные конструктором) который создает объект под конкретную структуру. По трудо-затратам думаю оба подхода близки, как на этапе разработки, так и на этапе эксплуатации. 

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


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

возможно. допустим, это выльется в код вроде
но 1) это будет КОД в каком-то методе ОТДЕЛЬНО от объявления класса, а атрибуты как раз позволяют собрать всё ДЕКЛАРАТИВНОЕ в одном месте и более наглядно представить
2) удобство просто пропустить (не задавать) атрибут, если он не нужен, вряд ли удастся как-то воспроизвести
тогда вам нужно поинтересоваться использованием аннотаций в джаве (annotations - там они так называются) - например, в hibernate и других открытых проектах (конкретных ссылок, увы, нет)
этого совсем не понял   
в чертеже паровоза на порядки проще и быстрее что-либо изменить, чем в самом паровозе, но ни там, ни там нельзя, скажем, просто взять и увеличить котел в 2 раза
тогда как в программе достаточно написать "const BoilerVolume = 200" вместо "... = 100" - и вуаля (это пример именно статической конфигурации) 
и хотя с директивами это сделать так же просто - "const BoilerVolume = {$IFDEF BIG_BOILER}200{$ELSE}100{$ENDIF}", программные IF-ы все-таки гибче директивных, не находите?
(в этой гибкости атрибуты и константы похожи, а преимущества атрибутов над константами я уже описывал)
а нельзя ли цитату с нарушением логики?   

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

И тут интересно даже то, что Entity является virtual, что значит когда я буду стучаться к этому свойству (его я не устанавливаю) - ORM достанет эту энтити само учитывая поле ChangedEntityId. И тут это как бы не сериализация, а доступ к данным. Для того чтобы это работало надо ещё иметь Emit (вот этого не хватает тоже в делфи). 

Продолжим как могут ещё использоваться атрибуты - пример из тренинга. Допустим мы сделали библиотеку для "обработки" методов в приложении и хотим его распространять. А чтобы пользователю было легко его использовать добавим атрибуты: CacheAttribute + ProfileAttribute. И теперь радостные пользователи будут это использовать так:



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

Дальше кастомная подсветка. Допустим, у нас имеется фрэймворк который работает как-то с файлами. И есть методы:
LoadFile("/dir/file.dat");
Как бы было классно написать дополнение для IDE которое подсвечивало зелёным и подчёркивало если файл есть и класным - файла нету - ошибочка. И тогда было было бы так:

AppFileAttribute будет использоваться аддоном IDE для подсвечивания ошибок - очень удобно. 


Зря иронизируете. Дополнительно это может выглядеть так:

И тут атрибутами указывается:
1) Библиотеку, откуда метод (в делфи без атрибутов обходятся)
2) EntryPoint (то же)
3) CharSet - вот тут уже в делфи нету - можно указать как конвертировать кодировки, удобно, блин
4) InAttribute, OutAttribute - я думаю понятно, к чему это, но в делфи можно и без этого обойтись - это ясно. 

Дальше пример с enum (не знаю, работает ли в делфи, но так используют другие языки):


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

конечно же зя. она опять прозвучала тремя строками выше

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


Вы мыслите как сишник, а в Delphi это будет выглядеть примерно так

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


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

Что больше никто не использует атрибуты в Delphi?

Вы только забыли привести пол километра кода который реализует данный механизм.

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


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

Хотя само применение интересно. Только не понятно как MyMethod1 отреагирует на появление атрибутов, если в нем не предусмотрена такая реакция изначально.

просто не могу понять зачем пятое колесо? Зачем заменять (делать альтернативу) уже имеющемуся механизму, причем весьма эффективному. 

Ну да... попытка подпереть мега баг языка кривым костылем... Конечно этого нет в Delphi! Работа со строками там интегрирована на уровне языка и проблем с конвертацией в априори не существует.

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

как ни странно но оно работало и до этого и еще 20 лет назад... Интересно наблюдать как происходит процесс "пере открытия" давно известных истин и механизмов. 
Плохо только что Delphi для большинства начинается и заканчивается на Form1.ButtonClick()...

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

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

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

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

Это сообщение отредактировал(а) PointerToNil - 24.7.2014, 16:33

Еще один шедевр... эффективность и удобство не измеряется в количестве символов, как и скорость разработки не зависит от скорости печатания символов.
 

как ни странно совершенно разном виде. Константы уходят в сегмент данных как есть, а атрибуты становятся частью сегмента кода и реализуются через конструкторы только в период исполнения в виде внутренних объектов RTTI.

наверно не следы, а собственно "их", а то как то странно наследили и делись куда то.

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

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

Вы лучше вдумайтесь в эту фразу: МОЖНО сравнивать различные по сути технологии.

опишите этот показатель, будьте добры... мне помнится в 80х зарплата программиста измерялась в строках (точнее количестве операторов) Вы на это намекаете? Или использование переменных 1-2х буквенной длинны эффективнее чем 6-8? 
А лучше не скобки расставляйте, а в смысл написанного вникните, может дойдет. А то в голове крутится одно, а на бумаге совсем другое ;)

Лично для PointerToNil, анекдот: Когда шахтер благодарит, то кажется что он посылает на х..., а когда интеллигент посылает на х... кажется что он благодарит. 


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

PointerToNil, Вы бы лучше по делу написали, про атрибуты.

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

  и температура у них 36.6 по ходу получилась


Применение! Как? Где? Зачем?

ок, последний оффтопик: старое уже (2000) эмпирическое сравнение семи языков программирования: 
http://www.osp.ru/os/2000/12/178361/

А разве это плохо? Конечный код лаконичен и прост, это самое главное. Я вам даю пример, то количество кода, которое стоит за примером - это никогда не волновало пока всё работает просто и быстро. Изменение поведения через аттрибут очень удобно.


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


ООП это не панацея, а инструмент, у него есть область применения и задачи. Я дал пример, в котором использовать наследование крайне не удобно - переписывать классы ради добавление кэша в один метод - неее, спасибо. Другое дело, что такая реализация требует IoC + возможность на лету создавать классы обёртки по интерфейсам, в делфи пока что вроде нельзя (поправите - был бы рад).


Вы имеете в виде директивы? Если да, то это разное. Директивы - это попадает ли код в сборку или нет, атрибуты - могут работать в и сборке и более того их поведение можно изменять в runtime, а также добавляют коду аннотации, которые доступны в runtime. Есть ли альтернатива добавдению аннотаций?


К чему этот холивар? Если хотите похоливарить - так и скажите. Я вам даю пример, а вы включайте мозг:

додумать можно ещё - было бы желание.


Пожалуйста, не разводите холивар - судя по всему карты не на вашей стороне.


Вы про http://theroadtodelphi.wordpress.com/2009/...g-using-delphi/ ? Так там есть большая проблема - я хотел бы называть вещи используя как минимум пробелы и спец. символы.


Посмотрите на jetbrains code annotations

P.S. Ещё раз просьба - ближе к теме, без нападок на языки.

поясните термин

понятие классы обертки тоже
Так понимаю "на лету"  - это реал тайм? 

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


Ну наконец то, первая светлая мысль в топике! Атрибуты это описания классов доступные в RT!
Только вот зачем они в Delphi? Прекрасно понятно, зачем они в сях всех мастей, зачем они в скриптовых языках, тоже не вызывает вопросов, а вот как их применять в Delphi?


Додумать что? Вы приводите шарповский код, с его "особенным" построением и вшитыми механизмами. Что додумывать?
Раздел форума Delphi, в вопросе четко обозначена среда, а Вы даете вырезки из синтаксически не совместимого языка, да еще и с использованием не опознанных фейерверков. Так кто холиварит? У меня нет претензий ни к каким языкам и платформам. Но какой смысл разбирать инвалидность шарпа в форуме посвященном Delphi, давайте лучше разбирать инвалидность Delphi, имхо пользы будет больше. 


Это понятно, и полностью согласен. Но механизм то есть, хотя и с ограничениями, как и все в этом мире.

Еще раз хочу сказать, что интересно применение именно в Delphi. Как и для чего атрибуты используются в других языках понятно.
Механизм есть, значит надо понять куда его применять. Если выяснится, что этот механизм (как и анонимные функции) внедрили "лишь бы соответствовать трэнду", то будем прописывать в виде атрибутов авторство и версии классов.

Извините, если погорячился.

Да, именно в runtime. Не только классы, а и сборки (dll - аналог). Без него надо использовать рефлексию (RTTI в делфи), а это медленно.


Вы можете пересмотреть тему - что с ними делают в других языках и применять с учётом delphi ограничений. Ваше непонимание вызвано малом распространением атрибутов в исходных кодах делфи, в сторонних библиотеках, и, что ещё вероятно, ограничениями языка, которые не позволяют делать достаточно динамичный код в зависимости от атрибутах на объектах. Я RTTI убирал из проектов своих т.е. это помогало уменьшить размер бинарников, а применение оных имеет смысл когда есть много готовых решений, которые упрощают жизнь уже сейчас без придумывания своих велосипедов. 


Смотрите шире. Даже в делфи это не только классы (каюсь - весь список не знаю), а в других языках это:
1) Описания для сборок

2) Описания для модулей
3) Для конструкторов, методов
4) Свойств + Филдов
6) Интерфейсов
7) Параметров методов


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


Например тут пример из разряда фабрики классов, когда фабрика использует атрибуты в свойствах для их автозаполнения. Удобно при тестировании когда вам надо 10 пользователей и вы пишите:

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


Также ликвидаторы объектов:


Код один для всего, нет нужды писать везде свои валидаторы для каждого типа.

по всей видимости это виртуализация и вряд ли появится в Delphi.


Да ошибся, под классами имел ввиду описатель RTTI, а они есть для всех типов. тоесть атрибут можно прицепить к любому типу.


если не сложно можете привести содержимое метода Get. Хочу понять насколько правильно его понимаю.
В нем идет последовательный перебор свойств класса и ... вызов функции атрибута? чтение значений атрибута и вызов сторонней функции и прочитанными значениями? 

В целом я согласен с Вами. Примеров реализаций практически нет, толковых вообще нет. Стратегия применения не описана... В базовом наборе исходных кодов атрибуты не найдены. Поэтому понять как разработчики видят применения атрибутов для меня остается загадкой.
Почему то вводя дженерики добавили аж три модуля с примитивами, под 10к строк кода... а с атрибутами полный глухарь...

Псевдокод:

Используя http://stackoverflow.com/questions/8355456...ed-generic-type + http://habrahabr.ru/post/85509/




Увы - приоритеты.

Это сообщение отредактировал(а) Illusion Dolphin - 25.7.2014, 23:03

Спасибо. Именно так и представлял.

только эту стороку интереснее было бы реализовать

вот так

Я бы не согласился, т.к. задача атрибута - это сделать пометку, а не генерировать имя. 2 задачи на один объект это нарушает принцип single responsibility. Именно поэтомк всё "самое интересное" не сами атрибуты обычно, а код, который их использует. 

Не знаю как в шарпе устроены внутренности атрибутов, и насколько там уместно говорить о методах и событиях для атрибутов. В делфи атрибут реализован в виде объекта который прицеплен к структуре RTTI. Следовательно атрибуты поддерживают все возможности объектов, и не вижу идеологических проблем в инкапсуляции функционала в класс конкретного атрибута.
А если кому то понадобится, то можно легко переопределить функционал путем наследования.
А так как в делфи нет возможности получить доступ к атрибутам на уровне языка, придется создавать набор инструментов, но этот набор должен быть максимально обобщенным и функционально должен только извлекать нужные объекты из структур RTTI.

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

в исходном коде поставляемом в delphi используется два атрибута [Stored] и [Default] это заменители одноименных ключевых слов. Судя по коду внутренних изменений механизм не претерпел. 

Часто используемые возможности (stored, default, index) изначально были реализованы и появление атрибутов (как отдельного механизма) не привело к разительному росту возможностей. Разве что появилась возможность, как бы, создавать свои под структуры в Rtti. 

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

Это сообщение отредактировал(а) drkot - 26.7.2014, 18:10

Это вопрос не по теме, но раз уже поднят... Есть такая вещь (это уже из области паттернов) как SOLID. Первая буквочка в этом - (S)ingle responsibility означает, что класс должен делать 1 (одну) задачу. Задача аттрибута - сделать пометку, которая может содержать данные (это по сути - данные RanomInt(1,100)). Если вы туда всуните генерацию данных, то просто нарушите принцип SOLID. Я винить вас за это не буду, но хотя бы на собеседованиях такого не делайте ;)


Очень даже интересно - осталось подождать когда кто-то сделает наконец-то всё то многообразие библиотек, которое присутствует в других языках. Главное - не опоздать ;)

Ключевой вопрос: а оно надо? Если кому не хватает RTL + VCL, то он их просто не умеет готовить.


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

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

Буду краток:
1) Не согласен
2) 1 тема один вопрос

А где второй вопрос?


Дык, Ваше право. 

Получается, что классовые константы и атрибуты имеют идентичную конечную реализацию
Возможно это распространяется на классовые переменные и функции.

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

Возможно не корректно выразился...
имеется ввиду, что и классовые константы и атрибуты, являются частью Класса, а не объекта.
А так как атрибуты являются объектами, то им необходимо создание.

ну я бы сказал что они являются частью RTTI