и температура у них 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 тема один вопрос