AVK>По моему это какая то ерунда. Если информация статична значит она в статик полях. Прочитать информацию из статик полей, не создавая экзепляра можно. Если же эта информация хранится таки в экземпляре значит эта информация не статична.
Ну, может, я плохо сформулировал, но, надеюсь, сама проблема понятна?
Да, информаци статична для конкретного типа. И еще она — виртуальна, потому что для тиров-потомков может отличаться. Я хочу, значя тип не точно, получить эту информацию, как я вызываю виртуальный метод объекта, не зная точно его типа. Чего ж тут неясного?
AVK>Точно изврат. А нафига? Что это за информация такая, что экземпляр нужен? AVK>Вот и интересно что это за задачи такие. Предыдущий оратор на этот вопрос заявил что у него времени мало и ему работать нужно. AVK>Что именно приходится делать через задницу?
Я привел пример задачи. И раньше приводил. Еще повторять?
AVK>Из парадигмы ООП? Ничуть. ООП не предполагает наличие неизвестных на стадии компиляции типов. Это уже другая парадигма — компонентная модель. А ее в С++ нет, не поддерживает он ее. Потому и метаданных нет.
Согласен. Ну, значит, это следует из парадигмы компонентной модели
Вот тип на этапе компиляции не известен. Но мне хочется про него информацию. Не только самую общую — как FullName, но и более детальную, если тип известен с точностью до некоторого супертипа.
В принципе в .net эту информацию можно вытаскивать через атрибуты — но это половинчатое решение. Потому что наличие/отсутствие атрибута определенного типа — это все-таки соглашение. А статический виртуальный метод — это жесткий контракт типа.
AVK>Вот и хотелось бы узнать зачем. Я как то ни разу потребности не испытал, хотя на Дельфи в свое время писал очень много.
Очень странно. А если заглянуть в исходники VCL и поискать там "class of" то почему-то находится прилично вхождений. Вот разработчикам VCL это все-таки почему-то нужно было И мне тоже бывало нужно.
AVK>Какие то они некудышние.
Замечательно!!! Пять баллов!
Все столько просили конкретные примеры задач, а когда им эти примеры выдают, выясняется, что они "какие-то не такие" Ну, да, "не такие". Потому что на C# не решаются по-человечески.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Ну, может, я плохо сформулировал, но, надеюсь, сама проблема понятна?
В том то и дело что нет.
iT>Да, информаци статична для конкретного типа. И еще она — виртуальна, потому что для тиров-потомков может отличаться. Я хочу, значя тип не точно, получить эту информацию, как я вызываю виртуальный метод объекта, не зная точно его типа. Чего ж тут неясного?
Что тебе мешает пользоваться рефлекшеном и атрибутами?
AVK>>Точно изврат. А нафига? Что это за информация такая, что экземпляр нужен? AVK>>Вот и интересно что это за задачи такие. Предыдущий оратор на этот вопрос заявил что у него времени мало и ему работать нужно. AVK>>Что именно приходится делать через задницу?
iT>Я привел пример задачи. И раньше приводил. Еще повторять?
Не, ты привел не пример задачи, а пример конкретного решения. Потому я и написал что твои при меры не годятся.
iT>Согласен. Ну, значит, это следует из парадигмы компонентной модели
Да. И рефлекшен + атрибуты очень неплохо в эту концепцию ложаться. Почему не как в Дельфи? Тоже вобщем то понятно — практика показала что Дельфи-лайк стиль слишком негибок и плохо себя ведет при полном отсутствии какой бы то ни было информации на момент компиляции. В условиях дотнета подобный подход показал бы себя еще хуже.
iT>Вот тип на этапе компиляции не известен. Но мне хочется про него информацию. Не только самую общую — как FullName, но и более детальную, если тип известен с точностью до некоторого супертипа.
При помощи рефлекшена ты можешь получить всю наличествующую информацию, а при помощи атрибутов добавить еще и свою собственную. Дельфовый стиль полезен на этапе компиляции. В рантайме он не дает абсолютно никаких преимуществ.
iT>В принципе в .net эту информацию можно вытаскивать через атрибуты — но это половинчатое решение.
Это более полное решение нежели в Дельфи. Чтобы это понять достаточно сравнить возможности Дельфевого Object Inspector и PropertyGrid дотнета.
iT> Потому что наличие/отсутствие атрибута определенного типа — это все-таки соглашение.
И это здорово, поскольку механика атрибутов ортогональна как системе типов рантайма, так и другим схемам атрибутов. А это значит что атрибутные схемы не будут вмешиваться в структуру программы. Сравни к при меру published в Дельфи и BrowsableAttribute в дотнете. Первое — расширение языка специально под конретные потребности разработчиков самого IDE. Второе абсолютно стандартная для дотнета механика, полный аналог которой ты можешь соорудить сам без каких либо затруднений.
iT> А статический виртуальный метод — это жесткий контракт типа.
Жесткий он только на этапе компиляции. Причем очень специфичный. Т.е. накладывающий строго определенные ограничения. Уж лучше тогда дженерики с их констрейнтами. Тоже не идеал, по куда гибче.
iT>Очень странно. А если заглянуть в исходники VCL и поискать там "class of" то почему-то находится прилично вхождений.
Я тебе скажу почему. Потому что в Дельфи нет рефлекшена.
iT> Вот разработчикам VCL это все-таки почему-то нужно было
Если бы они додумали мысль до конца я думаю они бы пришли к более гибкому решению. А так получился просто хак языка и рантайма под конкретную задачу.
AVK>>Какие то они некудышние.
iT>Замечательно!!! Пять баллов! iT>Все столько просили конкретные примеры задач, а когда им эти примеры выдают, выясняется, что они "какие-то не такие"
Потому что это примеры конкретных решений, а не задач.
iT> Ну, да, "не такие". Потому что на C# не решаются по-человечески.
Попытка слепо скопировать решения с одной платформы на другую никогда хорошо не кончались.
AVK>Что тебе мешает пользоваться рефлекшеном и атрибутами?
Ну, так и выкручиваюсь, если надо, но вообще атрибуты для решения этих задач по сравнению с виртуальными статическими членами имеют следующие существенные минусы:
1. Это банально неудобно. Сравни DataTypeClass.Name и выражение для вычисления атрибута.
2. Атрибуты могут содержать только неизменяемую информацию. И гарантированно известную на этапе компиляции.
3. Атрибут — необязателен. Его можно забыть поставить. Нет жесткого контракта.
AVK>Не, ты привел не пример задачи, а пример конкретного решения. Потому я и написал что твои при меры не годятся.
Задачи я тоже приводил. Извини, но если человек знает Delphi, то по трем строчкам решения понять задачу не должно составить труда. Впрочем, текстом я их тоже формулировал. В общем, демагогия пошла. Решения на шарпе не получаются — значит, переходим на критику задач
AVK>Да. И рефлекшен + атрибуты очень неплохо в эту концепцию ложаться. Почему не как в Дельфи? Тоже вобщем то понятно — практика показала что Дельфи-лайк стиль слишком негибок и плохо себя ведет при полном отсутствии какой бы то ни было информации на момент компиляции. В условиях дотнета подобный подход показал бы себя еще хуже.
Мнэ? Что ты подразумеваешь под Delphi-like? Чем бы было хуже, если бы в добавку к атрибутам была бы более жесткая возможность извлечения информации о типах??? Тут я не понял.
AVK>При помощи рефлекшена ты можешь получить всю наличествующую информацию, а при помощи атрибутов добавить еще и свою собственную. Дельфовый стиль полезен на этапе компиляции. В рантайме он не дает абсолютно никаких преимуществ.
Атрибуты — это мощно, как встроенный ассемблер Очень мощно. Но это более низкий уровень. Код, написанный с массовым применением атрибутов некрасив, многословен, изобилует проверками того, чего не должно быть.
Вернемся моей задачке — информаия о структре DataSet'а. Там может быть 10 методов. Воротить 10 атрибутов? Некрасиво, неудобно, уродливо!
Кстати, еще бы не помешали интерфейсы типа.
AVK>Это более полное решение нежели в Дельфи. Чтобы это понять достаточно сравнить возможности Дельфевого Object Inspector и PropertyGrid дотнета.
И какие между ними принципиальные отличия?
Учти, что дельфийскому ObjectInspectory уже 10 лет и он создавался, когда в языке вообще не было понятия интерфейса И вообще это нашей темы не касается. В обоих случаях нужна только обобщенная информация о типах, а мы говорили, о custom-информации о типах. Кстати, в Delphi можно было написать редактор свойства для уже существующего типа
iT>> Потому что наличие/отсутствие атрибута определенного типа — это все-таки соглашение.
AVK>И это здорово, поскольку механика атрибутов ортогональна как системе типов рантайма, так и другим схемам атрибутов. А это значит что атрибутные схемы не будут вмешиваться в структуру программы. Сравни к при меру published в Дельфи и BrowsableAttribute в дотнете. Первое — расширение языка специально под конретные потребности разработчиков самого IDE. Второе абсолютно стандартная для дотнета механика, полный аналог которой ты можешь соорудить сам без каких либо затруднений.
Я вовсе не отрицаю пользу атрибутов. И Абсолютно согласен, что [Browsable] — это качественно лучшее решение, нежели published.
iT>> А статический виртуальный метод — это жесткий контракт типа.
AVK>Жесткий он только на этапе компиляции. Причем очень специфичный. Т.е. накладывающий строго определенные ограничения. Уж лучше тогда дженерики с их констрейнтами. Тоже не идеал, по куда гибче.
А иногда жесткость — это имеенно то, что нужно. Что — не согласен? Может вернемся к позднему связыванию всех вызовов по имени метода? нет?
AVK>Я тебе скажу почему. Потому что в Дельфи нет рефлекшена.
Не-а. Не поэтому. Возможно, не только поэтому. Еще потому что там не было интерфейсов и еще потому, что там есть статические виртуальные члены
Хорошо, достаем пример из VCL. Любой TField имеет статический виртуальный метод, позволяющий проверить некоторое значение на корректность для данного поля. Это ты не сделаешь атрибутом. Для этого не нужно создавать экземпляр поля, потому что эта логика определяется его типом. И эта логика виртуальна.
Как это делать на C#? Ну, как водится — атрибут, содержащий тип, который реализует интерфейс проверки.
Вот это я и называю — через задницу Потому что длинннее, сложнее, лишнее создание никому ненужного экземпляра и т.п.
iT>> Вот разработчикам VCL это все-таки почему-то нужно было
AVK>Если бы они додумали мысль до конца я думаю они бы пришли к более гибкому решению. А так получился просто хак языка и рантайма под конкретную задачу.
Блин, ну почему — хак??? У одного — бред и изврат, у другого — хак...
А я скажу так — очень хорошая, полностью осмысленная, стройная языковая конструкция, чрезвычайно нужная при создании высокодинамичных систем. Криво, но эмулируемая с помощью атрибутов. Потому что ими все можно эмулировать, что имеет отношение к типам. Ими можно виртуальные методы эмулировать. легко! Давайте выкинем ключевые слова virtual, abstract, override и будем это делать с помощью атрибутов. Гибко! Ортогонально!
Почему имя типа — не атрибут? Почему предок типа — не атрибут?
AVK>Попытка слепо скопировать решения с одной платформы на другую никогда хорошо не кончались.
Смотрим выше про парадигмы. Delphi и C# — это не Perl и C#. Парадигмы очень близки. Задачи все очень похожи.
Отмазки, все гнилые отмазки.
ST>>>хотелось обсудить как это сделать попроще
M>>Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают. S> Хе хе. IL Ассемблер. Проще и главное быстрее????
А ну давай не махай руками! Что ты предлагаешь и почему считаешь, что это проще?
M>>Ну это здорово. Использовать, правда их по делу нельзя, но хоть появляются и то на душе потеплело
VD>
VD>Нда. Делфисты не меньшие маньяки чем С++-ники.
Э. Ну, просто мой сарказм был слишком сильно замаскирован
VD>Эх. Хорошо маньяки Кобола уже вымерли.
На последней Kiev .NET User Group один товарищ защищал VB и заодно и Кобол. Выглядело смешно, но у всех были такие умные лица, что я постеснялся гоготать
Здравствуйте, mihailik, Вы писали:
M>>>Может с шаблонами будет и проще немножко.
ST>>гораздо проще
M>Ты уверен? Поделись, интерестная головоломка.
M>Я тоже поначалу так подумал — генерики всё решат. Но вот прикинул на секундочку и вроде не получается.
M>Кажется, в .NET-генериках нельзя поставить restriction на существование статического метода. А без этого особого проку нет
Здравствуйте, Igor Trofimov, Вы писали:
AVK>>Что тебе мешает пользоваться рефлекшеном и атрибутами?
iT>Ну, так и выкручиваюсь, если надо, но вообще атрибуты для решения этих задач по сравнению с виртуальными статическими членами имеют следующие существенные минусы:
iT>1. Это банально неудобно. Сравни DataTypeClass.Name и выражение для вычисления атрибута.
Да никакой такой большой разницы нет. Особенно если лезть не напрямую, а через TypeDescriptor.
iT>2. Атрибуты могут содержать только неизменяемую информацию. И гарантированно известную на этапе компиляции.
Нет конечно. Это относится только к параметрам конструкторов.
iT>Задачи я тоже приводил. Извини, но если человек знает Delphi, то по трем строчкам решения понять задачу не должно составить труда.
Нет и еще раз нет. Это решения и ничего больше. По твои трем строчкам можно создать только очень близкое подобие, которое естественно будет кривым. Пытаться что то менять невозможно, поскольку это скорее всего приведет к изменению каких либо характеристик, а не зная исходной задачи понять допустимо ли это невозможно.
iT> Впрочем, текстом я их тоже формулировал.
Что то не заметил. Заметил только решения с использованием Дельфи.
iT>Решения на шарпе не получаются — значит, переходим на критику задач
Решения чего? Я тебе так же могу сказать — вот код
[XmlIgnore]
public string SomeProperty
{
}
Расскажи мне как подобную задачу решать на Дельфи? Что, не знаешь? Вот то то и оно.
AVK>>Да. И рефлекшен + атрибуты очень неплохо в эту концепцию ложаться. Почему не как в Дельфи? Тоже вобщем то понятно — практика показала что Дельфи-лайк стиль слишком негибок и плохо себя ведет при полном отсутствии какой бы то ни было информации на момент компиляции. В условиях дотнета подобный подход показал бы себя еще хуже.
iT>Мнэ? Что ты подразумеваешь под Delphi-like?
Решения вроде статической дельфевой виртуальности, виртуальных конструкторов, published модификатора и т.п.
iT>Чем бы было хуже, если бы в добавку к атрибутам была бы более жесткая возможность извлечения информации о типах???
В добавку? Тем что появилось бы две конструкции языка, решающие одну и ту же задачу. Это очень плохо.
iT>Атрибуты — это мощно, как встроенный ассемблер Очень мощно. Но это более низкий уровень.
Кастомные атрибуты более низкий уровень по сравнению с системой типов? Что то я совсем перестаю тебя понимать.
iT> Код, написанный с массовым применением атрибутов некрасив, многословен, изобилует проверками того, чего не должно быть.
Вы просто не умеете их готовить.
iT>Вернемся моей задачке — информаия о структре DataSet'а.
Какая информация?
iT> Там может быть 10 методов. Воротить 10 атрибутов?
Атрибуты вобще то можно еще и к классам применять. А если ума нет то можно еще к параметрам методов атрибуты прицепить, причем для каждого свой.
iT>Кстати, еще бы не помешали интерфейсы типа.
Вот вот, начинается хардкодная городильня. А атрибуты уже вполне способны интерфейсы реализовывать без дополнительных наворотов и заточек.
AVK>>Это более полное решение нежели в Дельфи. Чтобы это понять достаточно сравнить возможности Дельфевого Object Inspector и PropertyGrid дотнета.
iT>И какие между ними принципиальные отличия?
Под PropertyGrid не был заточен CLR и C#.
iT>Учти, что дельфийскому ObjectInspectory уже 10 лет и он создавался, когда в языке вообще не было понятия интерфейса
Ну коль такие аргументы пошли в ход тогда я тебя спрошу — почему ни в одном новом языке — будь то джава, шарп или vb.net нет статической виртуальности. Значит идея этой самой виртуальности оказалась неперспективной.
iT> И вообще это нашей темы не касается.
Касается, поскольку работает PG как раз на основе той самой информации, привязанной к конкретному типу. Красивое и очень мощное решение без необходимости прибегать к виртуальным статическим методам.
iT> В обоих случаях нужна только обобщенная информация о типах, а мы говорили, о custom-информации о типах.
Ты плохо себе представляешь что такое PG. Он способен понимать очень много кастомной информации. Попробуй например локализовать Object Inspector.
iT> Кстати, в Delphi можно было написать редактор свойства для уже существующего типа
Что смешного? В PG тоже можно. И это все что там можно сделать. А локализация? А состав свойств? А динамические свойства? А менять названия/видимость/редактор/все-что=хочешь у свойств на лету? Налицо значительное преимущество атрибутной модели дотнета над дельфовой.
iT>Я вовсе не отрицаю пользу атрибутов. И Абсолютно согласен, что [Browsable] — это качественно лучшее решение, нежели published.
Ну так с виртуальной статикой тоже самое. Атрибуты гибче, универсальнее и не завязаны на систему типов.
AVK>>Жесткий он только на этапе компиляции. Причем очень специфичный. Т.е. накладывающий строго определенные ограничения. Уж лучше тогда дженерики с их констрейнтами. Тоже не идеал, по куда гибче.
iT>А иногда жесткость — это имеенно то, что нужно. Что — не согласен?
Нет, потому что просто жесткость никому не нужна. Нужна управляемая жесткость. Дженерики позволяют жесткостью ограничений хоть как то управлять и не коррелировать с деревом наследования.
iT>еще потому, что там есть статические виртуальные члены
Мне это напоминает убежденность Мики в том что сессии веб-сервисов это преимущество сервисов перед ремоутингом.
iT>Как это делать на C#? Ну, как водится — атрибут, содержащий тип, который реализует интерфейс проверки. iT>Вот это я и называю — через задницу
Кому как. По мне так через задницу как раз первый вариант, поскольку если помимо TField мне понадобится такая же проверка в каком нибудь TProperty или TColumn я буду ее писать по новой. А если мне понадобится еще и перекрыть проверку у конкретного свойства типа TField то ситуация становится еще более фиговой.
AVK>>Если бы они додумали мысль до конца я думаю они бы пришли к более гибкому решению. А так получился просто хак языка и рантайма под конкретную задачу.
iT>Блин, ну почему — хак??? У одного — бред и изврат, у другого — хак...
Потому что хак. Узкий набор возможностей, которые были необходимы создателям VCL. Сделать что то сверх того, что делается в VCL невозможно.
iT>А я скажу так — очень хорошая, полностью осмысленная, стройная языковая конструкция, чрезвычайно нужная при создании высокодинамичных систем. Криво, но эмулируемая с помощью атрибутов.
Во! О чем я и говорю. Вместо того чтобы решать задачи вы эмулируете то что есть в Дельфи.
iT> Потому что ими все можно эмулировать, что имеет отношение к типам.
Не, не эмулировать. Это их предназначение — расширять информацию о типе. Точно так же можно сказать что статическая виртуальность эмулирует один из аспектов применения атрибутов.
iT> Ими можно виртуальные методы эмулировать. легко! Давайте выкинем ключевые слова virtual, abstract, override и будем это делать с помощью атрибутов. Гибко! Ортогонально! iT>Почему имя типа — не атрибут? Почему предок типа — не атрибут?
Потому что эти данные необходимы рантайму (не языку заметь, и не среде разработки).
AVK>>Попытка слепо скопировать решения с одной платформы на другую никогда хорошо не кончались. iT>Смотрим выше про парадигмы. Delphi и C# — это не Perl и C#. Парадигмы очень близки. Задачи все очень похожи.
Здравствуйте, mihailik, Вы писали:
M>>>Может с шаблонами будет и проще немножко.
ST>>гораздо проще
M>Ты уверен? Поделись, интерестная головоломка.
M>Я тоже поначалу так подумал — генерики всё решат. Но вот прикинул на секундочку и вроде не получается.
M>Кажется, в .NET-генериках нельзя поставить restriction на существование статического метода. А без этого особого проку нет
статической проверки типов действительно наверное не получится,
но писать меньше и copy/paste не требуется
м.б. что-то типа:
class RTTIMyClass : RTTIBase<MyClass>
{
}
а в RTTIBase есть что-то типа void execStaticMethod(name string);
впрочем, это все равно будет такой изврат. что проще обойтись без...
ST>впрочем, это все равно будет такой изврат. что проще обойтись без...
жить-то можно без этого. не понимаю. почему некоторые это так близко к сердцу восприняли
так же как можно жить без шаблонов, без переопределения операторов, без свойств, без ... чего-то еще
ST>а в RTTIBase есть что-то типа void execStaticMethod(name string);
По имени как-то некрасиво. Да и параметры, как ты параметры передавать будешь? Не, это не очень способ.
Я тут описывал примерно, как можно накрутить чтобы было прилично сносно. Делается интерфейс, в рантайме генерируется для него реализация-прокся под каждый класс. Должно работать без сильных тормозов.
M>>Кажется, в .NET-генериках нельзя поставить restriction на существование статического метода.
AVK>Хинт — статические методы могут возвращать вполне динамические экземпляры.
Вот не понял намёка
Генерики помогли бы, если бы можно было примерно так:
class StaticVirtualHelper<T>
{
public static DoSome(int a, int b, int c)
{
T.DoSome(a,b,c);
}
}
Но вызов T.DoSome() невозможен, так как нельзя потребовать от T наличия статического метода.
Здравствуйте, mihailik, Вы писали:
ST>>а в RTTIBase есть что-то типа void execStaticMethod(name string);
M>По имени как-то некрасиво. Да и параметры, как ты параметры передавать будешь? Не, это не очень способ.
M>Я тут описывал примерно, как можно накрутить чтобы было прилично сносно. Делается интерфейс, в рантайме генерируется для него реализация-прокся под каждый класс. Должно работать без сильных тормозов.
дык это вроде бы дельфя и делает
это да, здорово (в плане быстродействия), но проблема в том, чтобы работать с этим "до компиляции", т.е. не в рантайм
не понятно каков будет синтаксис вызова такого метода, если интерфейс еще не сгенерен ?
наверное, типа того :
FindInterfaceEntryFor('MyClass').ExecMyMethod('') — так ?
p.s.
кстати, можно будет в дотнете 1.2 создавать шаблоны для интерфейсов ? (это я о дженериках)
VD>Никогда этот бред в дотнете работать не будет. Нужно все же понимать, что Дельфи не всилах изменить структуру и функциональность дотнета.
Виртуальные статические методы в Delphi.NET присуствуют, это факт. Они, конечно, видны не как статические методы с точки зрения C#. В общем, польза от них возможна только не выходя из Дельфи.
А чего в кондуктора не пошёл? Родителей расстроить боишься? Ездил бы себе весь день по маршруту и никаких Микрософтовских инсинуаций не боялся.
ST>я вот поначалу радовался, но как колпнешь — нету счастия
А счастье в виртуальных статических классах?
Ты же знаешь, сейчас за деньги можно многое купить. Накопи денег, люди тебе C#-компилятор за милую душу перепишут. Я например, по бедности своей хохляцкой, всего за три штуки баксов встроил бы прямо в C# этот многострадальный static virtual. Чики-пуки, даже без суррогатностей.
И мне тоже бывало нужно.
