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


задача о том, где целесообразно использовать атрибуты в рамках 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 строк кода очень мало зависит от языка программирования, то есть чем длиннее код (при той же его функциональности или при большей - неважно), тем больше в нем ошибок
ок, и что же вам до сих пор еще не понятно в атрибутах?