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

вообще как это должно выглядеть по-нормальному ?

Здравствуйте, s.ts, Вы писали:

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

ST>вообще как это должно выглядеть по-нормальному ?
Они уже реализованы в Delphi через метаклассы.
http://www.rsdn.ru/Forum/Message.aspx?mid=548308&only=1

Автор: Serginio1
Дата: 24.02.04

Но это фича языка.

ST>>вообще как это должно выглядеть по-нормальному ?
S> Они уже реализованы в Delphi через метаклассы.
S> Но это фича языка.

Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(

Здравствуйте, Igor Trofimov, Вы писали:

ST>>>вообще как это должно выглядеть по-нормальному ?
S>> Они уже реализованы в Delphi через метаклассы.
S>> Но это фича языка.

iT>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(
Теперь есть. Завтра до работы попробую разобраться с Implements

iT>>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(
S> Теперь есть. Завтра до работы попробую разобраться с Implements

Ась? В шарпе? хде?

Здравствуйте, s.ts, Вы писали:

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

ST>вообще как это должно выглядеть по-нормальному ?

Зачем?

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

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

ST>>вообще как это должно выглядеть по-нормальному ?
S> Они уже реализованы в Delphi через метаклассы.
S>http://www.rsdn.ru/Forum/Message.aspx?mid=548308&only=1

Автор: Serginio1
Дата: 24.02.04

S> Но это фича языка.

виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

вот и вопрос как это реализовать попроще

и какие у этого перспективы

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Igor Trofimov, Вы писали:

ST>>>>вообще как это должно выглядеть по-нормальному ?
S>>> Они уже реализованы в Delphi через метаклассы.
S>>> Но это фича языка.

iT>>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(
S> Теперь есть. Завтра до работы попробую разобраться с Implements

что есть "Implements" ?
где смотреть ?

ST>виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

Ну, есть же RuntimeType, вот могли бы при инициализации типа делать singleton-потомок от него, описывающий конкретный тип. Эта штука и возвращалась бы по GetType(). Умела бы создавать экземпляры. Обеспечивала бы поддержку виртуальных (для экземпляра, соответственно — статических виртуальных) методов.

Зря не сделали такое в CLR.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

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

ST>>вообще как это должно выглядеть по-нормальному ?

VD>Зачем?

чтобы флейм не разводить на тему Delphi.net vs C#

меня интересует конкретные возможности языков

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

поэтому и задаю вопрос

Здравствуйте, Igor Trofimov, Вы писали:

ST>>виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

iT>Ну, есть же RuntimeType, вот могли бы при инициализации типа делать singleton-потомок от него, описывающий конкретный тип. Эта штука и возвращалась бы по GetType(). Умела бы создавать экземпляры. Обеспечивала бы поддержку виртуальных (для экземпляра, соответственно — статических виртуальных) методов.

не понял.
это руководство к действию для меня или для MS ?

iT>Зря не сделали такое в CLR.

а не собираются ?
а чего сейчас-то делать ?

ST>а не собираются ?

Вроде нет ;(

ST>а чего сейчас-то делать ?

Выкручиваться как-то.

Здравствуйте, Igor Trofimov, Вы писали:

ST>>а не собираются ?

iT>Вроде нет ;(

ST>>а чего сейчас-то делать ?

iT>Выкручиваться как-то.

дык какой путь имеет минимальные издержки на кодирование ?

никто не сталкивался ?

можно шаблоны использовать (те, что будут)

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, Igor Trofimov, Вы писали:

ST>>>а не собираются ?

iT>>Вроде нет ;(

ST>>>а чего сейчас-то делать ?

iT>>Выкручиваться как-то.

ST>дык какой путь имеет минимальные издержки на кодирование ?

ST>никто не сталкивался ?

ST>можно шаблоны использовать (те, что будут)

кстати, там чего-нибудь типа макросов не предвидится ?
то можно было бы изврат c rtii по типу mfc устроить ?

ST>кстати, там чего-нибудь типа макросов не предвидится ?
ST>то можно было бы изврат c rtii по типу mfc устроить ?

Извратов — лучше не надо.
Лучше без метаклассов — но не портить язык.

Здравствуйте, Igor Trofimov, Вы писали:

iT>>>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(
S>> Теперь есть. Завтра до работы попробую разобраться с Implements

iT>Ась? В шарпе? хде?
А что нельзя Дельфевые объекты в Шарпе использовать?????
Пиши классы на Delphi используй в шарпе.

Здравствуйте, s.ts, Вы писали:


ST>виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

Не совсем так. В нативном Delphi как таковых метаклассов нет. Есть VMT которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)
ST>вот и вопрос как это реализовать попроще

ST>и какие у этого перспективы
А чем тебе Дельфевая реализация не нравится????
Перпективы в ненужности использования рефлексии и простота использования наследников типов.

Здравствуйте, s.ts, Вы писали:

S>> Теперь есть. Завтра до работы попробую разобраться с Implements

ST>что есть "Implements" ?
ST>где смотреть ?
Директива Implements в Delphi говорить, что за реализацию интерфейса(ов) объекта, отвечает объект являющийся полем этого класса. То есть тебе не надо реализовывать все методы интерфеса в классе.
Но чего то у меня не получилось. Хотя директива осталась.

Здравствуйте, Igor Trofimov, Вы писали:

ST>>кстати, там чего-нибудь типа макросов не предвидится ?
ST>>то можно было бы изврат c rtii по типу mfc устроить ?

iT>Извратов — лучше не надо.
iT>Лучше без метаклассов — но не портить язык.

тогда придется ждать пока MS услышит глас вопиющего в пустыне

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

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:


ST>>виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

S> Не совсем так. В нативном Delphi как таковых метаклассов нет. Есть VMT которая располагается в две строны с положительным смещением виртуальные методы для экземпляров типа, с отрицательным для инфрмации о типе и виртуальных методов типа (виртуальных статических)
ST>>вот и вопрос как это реализовать попроще

могу добавить, типа чтобы все это еще умнее выглядело:

vmtSelfPtr = -76;
vmtIntfTable = -72;
vmtAutoTable = -68;
vmtInitTable = -64;
vmtTypeInfo = -60;
vmtFieldTable = -56;
vmtMethodTable = -52;
vmtDynamicTable = -48;
vmtClassName = -44;
vmtInstanceSize = -40;
vmtParent = -36;
vmtSafeCallException = -32 deprecated; // don't use these constants.
vmtAfterConstruction = -28 deprecated; // use VMTOFFSET in asm code instead
vmtBeforeDestruction = -24 deprecated;
vmtDispatch = -20 deprecated;
vmtDefaultHandler = -16 deprecated;
vmtNewInstance = -12 deprecated;
vmtFreeInstance = -8 deprecated;
vmtDestroy = -4 deprecated;

vmtQueryInterface = 0 deprecated;
vmtAddRef = 4 deprecated;
vmtRelease = 8 deprecated;
vmtCreateObject = 12 deprecated;


ST>>и какие у этого перспективы
S> А чем тебе Дельфевая реализация не нравится????
S> Перпективы в ненужности использования рефлексии и простота использования наследников типов.

нужна реализация для мэйнстрима (си шарп)

да и как я смогу использовать это в других языках ?

Здравствуйте, s.ts, Вы писали:

S>> А чем тебе Дельфевая реализация не нравится????
S>> Перпективы в ненужности использования рефлексии и простота использования наследников типов.

ST>нужна реализация для мэйнстрима (си шарп)

ST>да и как я смогу использовать это в других языках ?

кстати, создаваемые в дельфи @MetaИмя_класса — они являются потомками одного класса ?

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, s.ts, Вы писали:

S>>> А чем тебе Дельфевая реализация не нравится????
S>>> Перпективы в ненужности использования рефлексии и простота использования наследников типов.

ST>>нужна реализация для мэйнстрима (си шарп)

ST>>да и как я смогу использовать это в других языках ?

ST>кстати, создаваемые в дельфи @MetaИмя_класса — они являются потомками одного класса ?
Да от @Tclass. Но когда ты создаешь
VirtClass= class of BaseVirtClass;

Все вызовы Finction(VC:VirtClsass):Object;
трансформируются к
Finction(@MetaMyVirtClass.Instanse as BaseVirtClass)
Этим и достигается "статическая" виртуальность

Здравствуйте, s.ts, Вы писали:

ST>нужна реализация для мэйнстрима (си шарп)
Ну это будущее покажет C# стандартизован и ограничен в возможностях.
MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.
ST>да и как я смогу использовать это в других языках ?
Если классы создавать в Delphi то доступ
через @MetaClassName.@Instanse доступно на любом языке.
Либо ручками делать метаклассы.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

ST>>нужна реализация для мэйнстрима (си шарп)
S> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.
ST>>да и как я смогу использовать это в других языках ?
S> Если классы создавать в Delphi то доступ
S>через @MetaClassName.@Instanse доступно на любом языке.
S>Либо ручками делать метаклассы.

а во всех языках идентификатор может начинаться с @ ?

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, s.ts, Вы писали:

ST>>>нужна реализация для мэйнстрима (си шарп)
S>> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.
ST>>>да и как я смогу использовать это в других языках ?
S>> Если классы создавать в Delphi то доступ
S>>через @MetaClassName.@Instanse доступно на любом языке.
S>>Либо ручками делать метаклассы.

ST>а во всех языках идентификатор может начинаться с @ ?
Не знаю. Но странно, что в Net не была заложены изначально метаклассы, так как они есть во многих языках.

Здравствуйте, Serginio1, Вы писали:

S> Не знаю. Но странно, что в Net не была заложены изначально метаклассы, так как они есть во многих языках.

да уж то еще г...

я вот поначалу радовался, но как колпнешь — нету счастия

S> Ну это будущее покажет C# стандартизован и ограничен в возможностях

Ну ты маньячишь. Товарищ с вопросом пришёл, а ты ему Дельфи.

Нам бы таких активных в отдел маркетинга, быстро бы весь рынок захватили

ST>имхо нужно не за чистоту языка бороться, а как-то решать возникающиек проблемы

Реализовать метаклассы это проблема?

iT>>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(
S> Теперь есть.

Не тормози. В шарпе "теперь нет"

S>Пиши классы на Delphi используй в шарпе.

И шо, статические виртуальные методы появляются в шарпе?

ST>вообще как это должно выглядеть по-нормальному ?

Через Hashtable, атрибуты и рефлексию можно реализовать.

S> А что нельзя Дельфевые объекты в Шарпе использовать?????
S>Пиши классы на Delphi используй в шарпе.

не.. уходя — уходи.
Если уж пишем на C# — то лучше по возможности не использовать другое. От венигрета ничего хорошего не жди.

Здравствуйте, mihailik, Вы писали:

ST>>имхо нужно не за чистоту языка бороться, а как-то решать возникающиек проблемы

M>Реализовать метаклассы это проблема?

да
хочется минимум ручного кодирования

с шаблонами будет легче, но более-менее приличная реализация возможна только на уровне компилятора или макросов или я не прав

хотелось обсудить как это сделать попроще

S> Ну это будущее покажет C# стандартизован и ограничен в возможностях.

Ну, все-таки прогресс имеется — вот, дженерики сделали...
Авось и доберутся до метаклассов рано или поздно.
Хотелось бы конечно ускорить этот процесс, но как?
Ротор соотв. образом дописать — лично у меня ума не хватит.

Здравствуйте, mihailik, Вы писали:

S>>Пиши классы на Delphi используй в шарпе.

M>И шо, статические виртуальные методы появляются в шарпе?

метаклассы появляются

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

ST>>нужна реализация для мэйнстрима (си шарп)
S> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.

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

(это, знаете, похоже на "хороший программист, но как товарищ дерьмо")

Здравствуйте, mihailik, Вы писали:

ST>>вообще как это должно выглядеть по-нормальному ?

M>Через Hashtable, атрибуты и рефлексию можно реализовать.

а поподробнее можно ?

можно код не писать. а просто по пунктам: "берем это, делаем то, получаем т-а-а-а-к-о-о-о-е "

M>>Реализовать метаклассы это проблема?

ST>да
ST>хочется минимум ручного кодирования

Всем хочется


ST>с шаблонами будет легче, но более-менее приличная реализация возможна только на уровне компилятора или макросов или я не прав

Может с шаблонами будет и проще немножко.


ST>хотелось обсудить как это сделать попроще

Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают.

M>>И шо, статические виртуальные методы появляются в шарпе?

ST>метаклассы появляются

Ну это здорово. Использовать, правда их по делу нельзя, но хоть появляются и то на душе потеплело

ST>а поподробнее можно ?

1. Для виртуальности нужен контракт. То есть на каждый класс со статическими виртуальными членами нужно завести интерфейс.

2. Нужно завести специальный класс типа брокера, допустим VirtualStaticBroker. Ему передают typeof(Some) и он возвращает интерфейс. Типа VirtualStaticBroker.GetStaticInterface(...).

3. Скрытый класс, который реализует интерфейс придётся строить в Runtime посредством Reflection.Emit. Этой работой будет заниматься VirtualStaticBroker.

4. Чтобы не строить класс на каждый GetStaticInterface нужно его построить и запомнить в Hashtable.

5. Чтобы отделять виртуальные статические методы нужно завести самодельный атрибут вроде как VirtualAttribute.

Вот концептуально и весь сценарий.

Здравствуйте, Igor Trofimov, Вы писали:

S>> А что нельзя Дельфевые объекты в Шарпе использовать?????
S>>Пиши классы на Delphi используй в шарпе.

iT>не.. уходя — уходи.
iT>Если уж пишем на C# — то лучше по возможности не использовать другое. От венигрета ничего хорошего не жди.
Абсолютно не согласен с такой постановкой.
Нужно брать все самое лучшее из различных языков. Благо Net этому благоприятствует.
А вот если не ждать а пользоваться ...
Но на вкус и цвет ...

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, s.ts, Вы писали:

ST>>>нужна реализация для мэйнстрима (си шарп)
S>> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.

ST>по крайней мере настоящее показывает, что лучше от борланда подальше держаться

ST>(это, знаете, похоже на "хороший программист, но как товарищ дерьмо")
Мне по барабану — что ждать интересно что есть. И какая разница для MSIL откуда этот код ???
Главное что бы работал.

Здравствуйте, mihailik, Вы писали:


ST>>хотелось обсудить как это сделать попроще

M>Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают.
Хе хе. IL Ассемблер. Проще и главное быстрее????

S> Абсолютно не согласен с такой постановкой.
S> Нужно брать все самое лучшее из различных языков. Благо Net этому благоприятствует.

Ну да.. ради одного метода с параметром по умолчанию — лезть в VB, ради одного класса со статическим виртуальным методом — Delphi еще тянуть... нут уж, спасибо, как-нибудь перебьемся

Здравствуйте, Igor Trofimov, Вы писали:

S>> Абсолютно не согласен с такой постановкой.
S>> Нужно брать все самое лучшее из различных языков. Благо Net этому благоприятствует.

iT>Ну да.. ради одного метода с параметром по умолчанию — лезть в VB, ради одного класса со статическим виртуальным методом — Delphi еще тянуть... нут уж, спасибо, как-нибудь перебьемся
Во заодно помотрю и методы с параметрами.
А в чем проблема????
А как же раньше сишники то формы на Delphi или COM на VB????
Кстати не вижу проблемы. Да VS (видби другой коленкор) === Delphi 8.
Хозяин — Барин. Но почему то всегда хочется большего.

Здравствуйте, s.ts, Вы писали:

ST>разумнее, конечно, использовать C#, но хотелось бы знать во что мне выльется отсутствие некоей функциональности (автогенерация фабрик классов) в С#
ST>а может быть это появится через пол-года и там ?

ST>поэтому и задаю вопрос

Честно говря не очень ясно что за проблема с созданием фабрик. Копируешь файл делаешь одину замену по контексту и все.

Если тебе просто нужно унивесально создавать какой-нить объект, то вообще Activator.CtreateInstance...

Здравствуйте, mihailik, Вы писали:

ST>>с шаблонами будет легче, но более-менее приличная реализация возможна только на уровне компилятора или макросов или я не прав

M>Может с шаблонами будет и проще немножко.

гораздо проще


M>Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают.

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

как тут может помочь emit ? (что имелось ввиду ?)

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

ST>>Здравствуйте, Serginio1, Вы писали:

S>>>Здравствуйте, s.ts, Вы писали:

ST>>>>нужна реализация для мэйнстрима (си шарп)
S>>> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>>>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.

ST>>по крайней мере настоящее показывает, что лучше от борланда подальше держаться

ST>>(это, знаете, похоже на "хороший программист, но как товарищ дерьмо")
S> Мне по барабану — что ждать интересно что есть. И какая разница для MSIL откуда этот код ???
S>Главное что бы работал.

MSIL от борланд может и не работать...

кстати, попробовал я тут Delphi 8, дык геттер должен обязательно называтся "get_*" — ичего не напоминает ?

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

мне тут приходится на CLX писать

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

Здравствуйте, VladD2, Вы писали:

VD>Честно говря не очень ясно что за проблема с созданием фабрик. Копируешь файл делаешь одину замену по контексту и все.

ох##ть можно...
(ты сам оветил бы иначе на такие советы ?)

VD>Если тебе просто нужно унивесально создавать какой-нить объект, то вообще Activator.CtreateInstance...

это хоть что-то

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

А можно узнать что конкретно нужно? Задачку описать?

Здравствуйте, s.ts, Вы писали:

ST>ох##ть можно...
ST>(ты сам оветил бы иначе на такие советы ?)

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

VD>>Если тебе просто нужно унивесально создавать какой-нить объект, то вообще Activator.CtreateInstance...

ST>это хоть что-то

ST>в качестве ссылки что можно использовать ?
ST>имя класса можно ?
ST>или что другое ?

Что ты понимаешь под ссылкой? В МСДН или что туда совать?

В общем, без разницы. Пишел в МСДН-е "Activator class" в индексе и читаешь описание.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(

Ну, что ж. Остается только радоваться, что ты не программировал на С++ и Лиспе.

Здравствуйте, mihailik, Вы писали:

M>Ну это здорово. Использовать, правда их по делу нельзя, но хоть появляются и то на душе потеплело



Нда. Делфисты не меньшие маньяки чем С++-ники. Эх. Хорошо маньяки Кобола уже вымерли.

Здравствуйте, Serginio1, Вы писали:

S> Абсолютно не согласен с такой постановкой.
S> Нужно брать все самое лучшее из различных языков. Благо Net этому благоприятствует.
S>А вот если не ждать а пользоваться ...
S>Но на вкус и цвет ...

Одно не пойму, а нафиг тебе при этом Шарп.

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

Здравствуйте, Igor Trofimov, Вы писали:

ST>>виртуальные статические методы видимо не имеют смысла без метаклассов (тпа фабрик, что ли)

iT>Ну, есть же RuntimeType, вот могли бы при инициализации типа делать singleton-потомок от него, описывающий конкретный тип. Эта штука и возвращалась бы по GetType(). Умела бы создавать экземпляры. Обеспечивала бы поддержку виртуальных (для экземпляра, соответственно — статических виртуальных) методов.

iT>Зря не сделали такое в CLR.

Зечем? Для создания объекта в рантайме есть Activator.

Здравствуйте, s.ts, Вы писали:

ST>тогда придется ждать пока MS услышит глас вопиющего в пустыне

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

Ты чем воду мутить объяснил бы чего хочешь добиться. Мы бы тебе помогли. Представь себе вот программируем уже 2 года на шарпе и ни разу таких проблем как у тебя небыло.

Здравствуйте, mihailik, Вы писали:

M>Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают.

Сдается мне что ему нужно всего лишь в рантайме экземпляр какого-нить класса создать. И товаришь нифига не зная пытается найти решение аналогичное тому что он применял в Дельфи.

Здравствуйте, s.ts, Вы писали:

ST>конкретнее?
ST>я хочу, чтобы можно было сделать свойство типа "ссылка на класс"

А за фига? В такой постоновке вопроса тебе нужно написать:

class A
{
  static A a;
}

и все.

В общем, объясняй конечную задачу, а не свое решение.

ST>как тут может помочь emit ? (что имелось ввиду ?)

Эмит — это средство которое может помочь везде. Но это примерно как в дельфи программировать на встроенном ассемблере.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, s.ts, Вы писали:

ST>>нужна реализация для мэйнстрима (си шарп)
S> Ну это будущее покажет C# стандартизован и ограничен в возможностях.
S>MSDN Ресеч хочет рассширить возможности. В Delphi руки развязаны.
ST>>да и как я смогу использовать это в других языках ?
S> Если классы создавать в Delphi то доступ
S>через @MetaClassName.@Instanse доступно на любом языке.
S>Либо ручками делать метаклассы.

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

Здравствуйте, s.ts, Вы писали:

ST>а во всех языках идентификатор может начинаться с @ ?

Ага. Кроме С++, C# и VB.

В Шарпе это признак того что следущей за ним идертификатор не является ключевым словом.

Здравствуйте, Serginio1, Вы писали:

S> Не знаю. Но странно, что в Net не была заложены изначально метаклассы, так как они есть во многих языках.

Можено узнать в каких? И зафига все это в дотнете? В нем же рантайм объекты создает.

Здравствуйте, mihailik, Вы писали:

M>Ну ты маньячишь. Товарищ с вопросом пришёл, а ты ему Дельфи.

M>Нам бы таких активных в отдел маркетинга, быстро бы весь рынок захватили

А вы там дельфи продаете?

Здравствуйте, AndrewVK, Вы писали:

AVK>А можно узнать что конкретно нужно? Задачку описать?

Вообще уже пора всех разыскивающий метаклассы банить. Причем отбанивать только полсе того как пришлют на модераторский мэйл писмо с писменными заверениями, что прочли раздел МСДН посвященный классу Activator и его методу CreateInstance.

Здравствуйте, VladD2, Вы писали:

VD>В общем, без разницы. Пишел в МСДН-е "Activator class" в индексе и читаешь описание.

Ok. посмотрю. закрыто.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>конкретнее?
ST>>я хочу, чтобы можно было сделать свойство типа "ссылка на класс"

VD>А за фига? В такой постоновке вопроса тебе нужно написать:
VD>

VD>class A
VD>{
VD>  static A a;
VD>}
VD>

VD>и все.


VD> static A a;
это ссылка на экземпляр класса, а не на класс

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mihailik, Вы писали:

M>>Reflection + Reflection.Emit + атрибуты в такого типа задачах обычно нормально срабатывают.

VD>Сдается мне что ему нужно всего лишь в рантайме экземпляр какого-нить класса создать. И товаришь нифига не зная пытается найти решение аналогичное тому что он применял в Дельфи.

сдается мне, это ты, камрад, не понимаешь о чем речь идет

впрочем, обойдемся без взаимных оценок

и со своим createInstance ты мимо кассы попал

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>тогда придется ждать пока MS услышит глас вопиющего в пустыне

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

VD>Ты чем воду мутить объяснил бы чего хочешь добиться. Мы бы тебе помогли. Представь себе вот программируем уже 2 года на шарпе и ни разу таких проблем как у тебя небыло.

меньше знаешь — крепче спишь

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, VladD2, Вы писали:

VD>>В общем, без разницы. Пишел в МСДН-е "Activator class" в индексе и читаешь описание.

ST>Ok. посмотрю. закрыто.

посмотрел
мимо

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndrewVK, Вы писали:

AVK>>А можно узнать что конкретно нужно? Задачку описать?

VD>Вообще уже пора всех разыскивающий метаклассы банить. Причем отбанивать только полсе того как пришлют на модераторский мэйл писмо с писменными заверениями, что прочли раздел МСДН посвященный классу Activator и его методу CreateInstance.

опять мимо

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

заведи ветку под названием "Activator.CreateInstance" — там обсудим твое предложение (в данном случае оно бессмысленно, а почему — подумай малость)

Здравствуйте, AndrewVK, Вы писали:

AVK>А можно узнать что конкретно нужно? Задачку описать?

дык задачки-то я сам решу просто почти всегда есть несколько способов. одни лучше, другие хуже. я верю, что и вы для решения моей конкретной задачи мне запросто найдете десяток иных способов. вопрос был по конкретной функциональности (static virtual) и ее реализации определенными средствами (.net, возможно, версии 1.2 + C#, возможно версии 2). со своими конкретными задачами я и сам разберусь.

Здравствуйте, s.ts, Вы писали:

VD>> static A a;
ST>это ссылка на экземпляр класса, а не на класс

static Type a;

Здравствуйте, s.ts, Вы писали:

ST>дык задачки-то я сам решу просто почти всегда есть несколько способов. одни лучше, другие хуже. я верю, что и вы для решения моей конкретной задачи мне запросто найдете десяток иных способов.
ST>вопрос был по конкретной функциональности (static virtual) и ее реализации определенными средствами (.net, возможно, версии 1.2 + C#, возможно версии 2).

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Igor Trofimov, Вы писали:

iT>>Кстати, уже несколько раз с огорчением обнаруживал, что этой замечательной вещи мне после Delphi в шарпе не хватает ;(

VD>Ну, что ж. Остается только радоваться, что ты не программировал на С++ и Лиспе.

не знаю как уж там в лиспе, но в с++ сабж. реализуется запросто (шаблоны+макросы)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mihailik, Вы писали:

M>>Ну это здорово. Использовать, правда их по делу нельзя, но хоть появляются и то на душе потеплело

VD>

VD>Нда. Делфисты не меньшие маньяки чем С++-ники. Эх. Хорошо маньяки Кобола уже вымерли.

все маньяки плохо кончают (и маньяки дотнета тоже — понятно к чему я ?)

Здравствуйте, AndrewVK, Вы писали:

вопрос закрыт.

опять флейм получился.

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

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

думаю,ь что тему можно закрыть.

Здравствуйте, s.ts, Вы писали:

ST>все маньяки плохо кончают (и маньяки дотнета тоже — понятно к чему я ?)

Понятно, понятно... понятно что Шарп у тебя второй язык.

Здравствуйте, s.ts, Вы писали:

ST>не знаю как уж там в лиспе, но в с++ сабж. реализуется запросто (шаблоны+макросы)

Ты себе плохо представляешь задачу. С++ язык статический. И в чтобы сделать каие-нибудь рантайм-навороты нужно ой как попатеть.

Здравствуйте, s.ts, Вы писали:

ST>это ссылка на экземпляр класса, а не на класс

А сделать ссылку на абстракцию невозможно. Даже в Дельфи ты получаешь некий сурогат.

Здравствуйте, s.ts, Вы писали:

ST>и со своим createInstance ты мимо кассы попал

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

Здравствуйте, s.ts, Вы писали:

ST>меньше знаешь — крепче спишь

Точно. Сразу видно мастреа.

Здравствуйте, s.ts, Вы писали:

ST>посмотрел
ST>мимо

А куда стрелял то?

Здравствуйте, s.ts, Вы писали:

ST>опять мимо

Слушай, меня твоя игра в морской бой несколько раздражает. Ты или иди "крепче спать". Или объясняй толком что ты хочешь добиться?

ST>я что, должен, искать в топике все твои однообразные высказывания и отвечать односложно ? зачем дублировать сообщения в разных ветках ?

Ты вот это читал?

ST>заведи ветку под названием "Activator.CreateInstance" — там обсудим твое предложение (в данном случае оно бессмысленно, а почему — подумай малость)

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

Здравствуйте, AndrewVK, Вы писали:

AVK>На этот вопрос тебе давно ответили — нету. А для того чтобы сказать что есть вместо нужна конкретная задачка в которо тебе это понадобилось.

АВК, снеси этот морской бой во флйм. Там как раз давно таких умных тем небыло.

Здравствуйте, s.ts, Вы писали:

ST>и опять во многом благодаря VladD2, который всех назвал дураками и таким образом решил поставленную задачу

А по моему прежде всего благодаря тебе. Ты так и не ответил нафига оно тебе нужно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>все маньяки плохо кончают (и маньяки дотнета тоже — понятно к чему я ?)

VD>Понятно, понятно... понятно что Шарп у тебя второй язык.

в каком смысле ?

1. если в смысле второй по степени владения, а 1-м считать русский, то ты мне явно льстишь

2. если второй по счету, а первым ты считаешь какой-то другой ЯП, то ты меня явно недооцениваешь

не поверишь:

c, c++, matlab, clipper ( несколько ассемблеров и языков субд — не в счет ?) последний год/полтора — дельфи (турбо-паскаль в детском возрасте, видать, тоже не в счет ), далее, кажется, с#

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

такие, млин, дела

в общем, что бы ты не имел ввиду, опять пальцем в небо

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>не знаю как уж там в лиспе, но в с++ сабж. реализуется запросто (шаблоны+макросы)

VD>Ты себе плохо представляешь задачу. С++ язык статический. И в чтобы сделать каие-нибудь рантайм-навороты нужно ой как попатеть.

при чем тут рантайм-навороты ?

закроем...

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>и со своим createInstance ты мимо кассы попал

VD>У тебя касса замаскирована. Если бы ты скзал, что тебе нужно, то и проблем не было бы. А ты вмето этого пытаешся применять опыт полученый на не аналогичном продукте. Причем делашь это бездумно и упорно.

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

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

опять раздули черти-что

на работу-то время остается? или вся жизнь в форуме ?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>меньше знаешь — крепче спишь

VD>Точно. Сразу видно мастреа.

это я про тебя

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>посмотрел
ST>>мимо

VD>А куда стрелял то?

ты цитирование удалил, чтобы не иметь ответа на свой вопрос чуть выше?

ок. размещаю его ниже:

R>

ST>Здравствуйте, VladD2, Вы писали:

VD>>В общем, без разницы. Пишел в МСДН-е "Activator class" в индексе и читаешь описание.

ST>Ok. посмотрю. закрыто.

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

Угу. И очень жаль, что нет этого, как ты выразился "бреда".
Имхо, "бред" — это скорее inplace-делегаты и yield (или как он правильно пишется?).
А точнее, не бред — а не такая уж и нужная и бесспорная вещь.

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

Или, например, возможность узнать у типа какую-то информацию о типе, но не только банальный FullName, а что-то более интересное.

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

VD>Зечем? Для создания объекта в рантайме есть Activator.

Затем. Работа с типами не ограничивается банальным созданием экземпляра. Выше я привел два конкретных примера задач.

Здравствуйте, s.ts, Вы писали:

ST>c, c++, matlab, clipper ( несколько ассемблеров и языков субд — не в счет ?) последний год/полтора — дельфи (турбо-паскаль в детском возрасте, видать, тоже не в счет ), далее, кажется, с#

ST>перечислил только то, на чем больше года писал каждый день (ефстефстфенно, не в академических целях)

ST>такие, млин, дела

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

ST>в общем, что бы ты не имел ввиду, опять пальцем в небо

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

Здравствуйте, Igor Trofimov, Вы писали:

iT>Угу. И очень жаль, что нет этого, как ты выразился "бреда".
iT>Имхо, "бред" — это скорее inplace-делегаты и yield (или как он правильно пишется?).
iT>А точнее, не бред — а не такая уж и нужная и бесспорная вещь.

Это все синтаксический сахар. Ничего концептуального. Удобно, только и всего.

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

ДаунКастинг принципиально не может быть опасным. Ты видимо имел ввиду наоборт АпКастинг.

Честно говоря вообще не ясно зачем вы там химичите в таких объемах. Ну, да ваше дело. То что было в Дешьфи — это чистой воды грязный хак. Причем от АпКастинга он не спасает. Один фиг придется делать приведение. Ни в одной книге по ООП ты не найдеш такой фичи как в дельфи.

iT>Или, например, возможность узнать у типа какую-то информацию о типе, но не только банальный FullName, а что-то более интересное.

А в чем проблема?

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

Да нет проблем. Типизированный датасет — это обычный класс дотнета. Получай его описание в виде Type и читай все что хочешь. Вот только зачем тебе это? В рантайме куда удобнее и быстрее читать обычный датастет (если он создан динамически), а если он создан статически, то нифига фигней заниматься используй его как известный тип и будет тебе счастье.

iT> Было бы неплохо.
iT>Расскажи, как вы, выходцы из C++, обделенного такими возможностями, решаете подобные задачи.

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

Что же касается "вы... из С++"... у меня нет отдельной любви к С++, хотя на нем я программировал наверно дольше всего. Я и на дельфи года три пописал. Так что более чем реально представляю возможности. У дотнетных языков возможностей не меньше, просто их нужно с умом и по месту использовать. Задница как раз и начинается, когда пытаются эмулировать что-то на чем-то не вместо того чтобы решать свои задачи оптимальным образом.

Здравствуйте, s.ts, Вы писали:

ST>при чем тут рантайм-навороты ?

При том, что то что ты называешь виртуальными статическими функциями и ссылками на класс — это все фасад за которым кроется рантайм.

ST>закроем...

ОК.

Здравствуйте, s.ts, Вы писали:

ST>можно было ответить односложно :
ST>" нет. никак. не предвидится. лучшее, что можешь сделать — создавать фабрики классов. для автоматизации этой работы используй меню правка->заменить...других идей у меня нет..."

Тебе это человек пять ответило, но тебе же мало.

ST>ну а у кого есть идеи лучше, чем меню "замена", могут высказать свое мнение. и ведь пытались, кабы не появился тут некий "борец за непонятно что, но против" с ответами типа "а зачем?"

Вообще-то это вопрос. Но можно ответить и так. На дурацкие вопросы даем одекватные ответы.

ST>на работу-то время остается? или вся жизнь в форуме ?
ST>

Ты в календарь заглядываешь?

И вообще, что-бы не заботиться о своем благосостоянии, работе и т.п. У меня то проблем ни с работой, ни с зарплатой нет. Чего и вам желаю.

Здравствуйте, s.ts, Вы писали:

VD>>А куда стрелял то?

ST>ты цитирование удалил, чтобы не иметь ответа на свой вопрос чуть выше?

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

VD> ДаунКастинг принципиально не может быть опасным. Ты видимо имел ввиду наоборт АпКастинг.

Ну это как дерево рисовать С корнем внизу или с корнем наверху.

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

VD>Да нет проблем. Типизированный датасет — это обычный класс дотнета. Получай его описание в виде Type и читай все что хочешь.

Замечательно. Как мне из его Type прочитать, сколько таблиц входит в этот typed DataSet и какие у них колонки? Создавать только для этого экземпляр я не хочу — это уродливо!

Заметь, эта информация статична по отношению к конкретному типу датасета — она общая для всех его экземпляров. Хочется получить ее обобщенно из типа. Зная, что этот тип — подтип типа DataSet.

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

Язаметил, ты очень любишь всякие нехорошие слова "Бред, изврат"
Изврат — это создавать экземпляр объекта, чтобы получить информацию, общую для всех экземпляров, то есть информацию о типе.

VD>Что же касается "вы... из С++"... у меня нет отдельной любви к С++, хотя на нем я программировал наверно дольше всего. Я и на дельфи года три пописал. Так что более чем реально представляю возможности. У дотнетных языков возможностей не меньше, просто их нужно с умом и по месту использовать. Задница как раз и начинается, когда пытаются эмулировать что-то на чем-то не вместо того чтобы решать свои задачи оптимальным образом.

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

Языки можно сравнивать, если они работают в некоторой общей парадигме (имхо, поэтому C# и Perl несравнимы, а C#, Delphi, Java — сравнимы).

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

Вот точно также и возможности, о которых мы тут говорим, вытекают из парадигмы. Да, они нужны чуть реже, без них обойтись, выкрутиться, проще, чем без Activator.CreateInstance. Но они очень логично и целостно вписываются в общую картину. Поэтому когда в одном языке эти возможности есть, а в другом — их нет, просто нет, это как минимум вызывает недоумение. ПОЧЕМУ их нет? И не говори, что они не нужны. Нужны.

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

Итак, я привел тебе два конкретных примера, когда мне хочется расширенной информации о типе на уровне языка — расскажи, как их "оптимально решать" в C#.

решения на Delphi примерно такие:

1. Передача типа — потомка заданного типа

type TControlClass = class of TControl;
procedure AddControl(ControlClass : TControlClass);

2. Извлечение информации о типе, специфичной для всех типов — подтипов заданного

// Базовый тип
type DataSet = class(Component)
   ... 
   // Виртуальный член типа
   class function GetDataSetName : string; virtual;
   ...
end;

// Ссылка на тип, производный от базового
TDataSetClass = class of TDataSet;
...
// Переменная ссылки на такой тип
var DataSetClass : TDataSetClass;
....
// Извлечение информации о конкретном типе
ShowMessage(DataSetClass.GetDataSetName);

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, s.ts, Вы писали:

ST>>c, c++, matlab, clipper ( несколько ассемблеров и языков субд — не в счет ?) последний год/полтора — дельфи (турбо-паскаль в детском возрасте, видать, тоже не в счет ), далее, кажется, с#

ST>>перечислил только то, на чем больше года писал каждый день (ефстефстфенно, не в академических целях)

ST>>такие, млин, дела

VD>Возможно. Но то упорство с которым ты пытаешся получить отсуствующую и не нужную возможность наводит на мысли. Странно, что ты не потребовал множественного наследования, обработки формул в мат-виде, и изам-инструкций для управления БД.

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

ST>>в общем, что бы ты не имел ввиду, опять пальцем в небо

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

ладно, мир
уже суббота а я еще на работе

p.s. очередной раз предлагаю ввести правило, что участники обсуждений обходятся без взаимных оценок и ярлыков (мне что, теперь ник менять на "A1потопил"? ), а также не занимаются оценкой знаний друг друга (короче, следят за базаром ) — надоело читать "ты не знаешь/не понимаешь-сам не знаешь/не понимаешь"

Здравствуйте, Igor Trofimov, Вы писали:

iT>Замечательно. Как мне из его Type прочитать, сколько таблиц входит в этот typed DataSet и какие у них колонки? Создавать только для этого экземпляр я не хочу — это уродливо!

iT>Заметь, эта информация статична по отношению к конкретному типу датасета — она общая для всех его экземпляров. Хочется получить ее обобщенно из типа. Зная, что этот тип — подтип типа DataSet.

По моему это какая то ерунда. Если информация статична значит она в статик полях. Прочитать информацию из статик полей, не создавая экзепляра можно. Если же эта информация хранится таки в экземпляре значит эта информация не статична.

iT>Изврат — это создавать экземпляр объекта, чтобы получить информацию, общую для всех экземпляров, то есть информацию о типе.

Точно изврат. А нафига? Что это за информация такая, что экземпляр нужен?

iT>Никто не собирается ничего "эмулировать". Задачи, которые я приводил — вытекают не из возможностей Delphi или другого языка, где это есть, а из самой парадигмы ООП.

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

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

Что именно приходится делать через задницу?

iT>И вот, просто работая в рамках концепции ООП и возникают все эти задачки.
iT>Возьмем тот же С++, думаю, не будешь отрицать, что там работа с типами вообще очень сильно ограничена. А хочется. Почему хочется? Потому что это логично вытекает из парадигмы.

Из парадигмы ООП? Ничуть. ООП не предполагает наличие неизвестных на стадии компиляции типов. Это уже другая парадигма — компонентная модель. А ее в С++ нет, не поддерживает он ее. Потому и метаданных нет.

iT>Вот точно также и возможности, о которых мы тут говорим, вытекают из парадигмы. Да, они нужны чуть реже, без них обойтись, выкрутиться, проще, чем без Activator.CreateInstance. Но они очень логично и целостно вписываются в общую картину. Поэтому когда в одном языке эти возможности есть, а в другом — их нет, просто нет, это как минимум вызывает недоумение. ПОЧЕМУ их нет? И не говори, что они не нужны. Нужны.

Вот и хотелось бы узнать зачем. Я как то ни разу потребности не испытал, хотя на Дельфи в свое время писал очень много.

iT>Ты же постановил аксиомой — "в .net языках есть все, что нужно, кому этого мало — тот дурак".

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

iT>Итак, я привел тебе два конкретных примера,

Какие то они некудышние.

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>>Может с шаблонами будет и проще немножко.

ST>гораздо проще

Ты уверен? Поделись, интерестная головоломка.

Я тоже поначалу так подумал — генерики всё решат. Но вот прикинул на секундочку и вроде не получается.

Кажется, в .NET-генериках нельзя поставить restriction на существование статического метода. А без этого особого проку нет

AVK>static Type a;

Это поле будет одно на все классы-потомки. А нужно для каждого класса своё, но доступное как бы "виртуально".

Ну, это я поясняю, что товарищу хочется. Мне после Дельфи это хорошо понятно

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>Кажется, в .NET-генериках нельзя поставить restriction на существование статического метода.

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

Здравствуйте, 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>MSIL от борланд может и не работать...

Всем наездам наезд. Главное и ответить нечего. Да, может и не работать. Так же как и IL от Микрософта. Может.

ST>уже рука моя колоть устала

Правильно тебе Влад советует. Забей. Оно тебе надо колоть?

iT>Ротор соотв. образом дописать — лично у меня ума не хватит.

А денег? За 500 баксов я бы сделал суррогатную статическую виртуальность для C#. Надо?

ST>да уж то еще г...

А чего в кондуктора не пошёл? Родителей расстроить боишься? Ездил бы себе весь день по маршруту и никаких Микрософтовских инсинуаций не боялся.


ST>я вот поначалу радовался, но как колпнешь — нету счастия

А счастье в виртуальных статических классах?

Ты же знаешь, сейчас за деньги можно многое купить. Накопи денег, люди тебе C#-компилятор за милую душу перепишут. Я например, по бедности своей хохляцкой, всего за три штуки баксов встроил бы прямо в C# этот многострадальный static virtual. Чики-пуки, даже без суррогатностей.

Всего 3000 долларов за счастье, это же так мало!

VD>>Ты чем воду мутить объяснил бы

ST>меньше знаешь — крепче спишь

Верно. Кстати, что ты хотел узнать?

ST>не понятно каков будет синтаксис вызова такого метода, если интерфейс еще не сгенерен ?

Типа такого:

IMyStaticInterface staticIntf = StaticVirtualHelper.GetStaticInterface(
    typeof(IMyStaticInterface),
    typeof(MyClass) )
  as IMyStaticInterface;

staticIntf.DoSome( a1, b1, c1 );

ST>p.s.
ST>кстати, можно будет в дотнете 1.2 создавать шаблоны для интерфейсов ? (это я о дженериках)

Например IList<T>, это тебя интересует? Есть такое дело.

ST>>впрочем, это все равно будет такой изврат. что проще обойтись без...

ST>жить-то можно без этого. не понимаю. почему некоторые это так близко к сердцу восприняли

А кто же кроме тебя это поймёт? Да и как-то невежливо было тебе советовать сходить к психоаналитику

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

Можно-можно. Delphi.NET генерирует вполне разумный IL.

Просто это не static virtual в понимании IL. Отдельный workaround, скрытые метаклассы и т.п.

По части workaround они в Delphi хорошо поработали. Я где-то полгода назад читал, что там наворотили. Очень прикольно, ловкачи просто.

Жаль, что это теперь мало кому нужно.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

S>> Абсолютно не согласен с такой постановкой.
S>> Нужно брать все самое лучшее из различных языков. Благо Net этому благоприятствует.
S>>А вот если не ждать а пользоваться ...
S>>Но на вкус и цвет ...

VD>Одно не пойму, а нафиг тебе при этом Шарп.

Ну мне много надо. Честно говоря читая код на шарпе а затем на паскале не чувствуешь разницы как и писать. Но лучшее в этих языках хотелосьбы использовать.
VD>Кстати, почти уверен что для менеджед-классов этой фигни с виртуальными статическими методами сделать будет нельзя. В дотнете просто нет этого бреда.
Ну насчет Бреда это ты погорячился. Бред в том, что в Net такого нет.
Борланд просто автоматом делает метаклассы
http://www.rsdn.ru/Forum/Message.aspx?mid=548308&amp;only=1

Автор: Serginio1
Дата: 24.02.04

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, s.ts, Вы писали:

ST>>и опять во многом благодаря VladD2, который всех назвал дураками и таким образом решил поставленную задачу

AVK>А по моему прежде всего благодаря тебе. Ты так и не ответил нафига оно тебе нужно.
Обычно такое нужно когда гора классов наследников от одного базового класса.
Например Component или Control или иные случаи когда нужно единообразное создание экземпляров тип, однозначно что бы эти типы были наследниками от базового типа и несли специфическую информацию об этом типе. Конечно все это легко реализуется и через отображение, но это тормозно и нетипизировано.
Кстати Борланд с каждым классом ассоциирут и метакласс

function _GetMetaFromHandle(ATypeHandle: System.RuntimeTypeHandle): _TClass;
var
  t, save: System.Type;
  ancestor: _TClass;
  ctorInfo: System.Reflection.ConstructorInfo;
begin
  InitMetaTypeMap;

  Result := _TClass(MetaTypeMap[ATypeHandle]);
  if not Assigned(Result) then
  begin
    save := System.Type.GetTypeFromHandle(ATypeHandle);
    t := save;
    if not t.IsSubClassOf(TypeOf(_TClass)) then
    begin
      t := t.GetNestedType('@Meta' + t.name,
        BindingFlags.Public or BindingFlags.NonPublic);
    end;
    if Assigned(t) then
      Result := _TClass(t.GetField('@Instance').GetValue(nil))
    else
    begin                  // Requested type is not a Delphi class
      t := save.BaseType;
      if Assigned(t) then
      begin                // Is it a descendent of a Delphi class?
        ancestor := _GetMetaFromHandle(t.TypeHandle);
        t := System.Object(ancestor).GetType;
        if t.IsSubClassOf(TypeOf(_TClass)) then
        begin              // yes! descendent of a Delphi class
          ctorInfo := t.GetConstructor(System.Type.EmptyTypes);
          if Assigned(ctorInfo) then
          begin            // construct an instance of the Delphi classref
                           // but set its instancetypehandle to this non-Delphi type
            Result := _TClass(ctorInfo.Invoke(nil));
            Result.SetInstanceType(ATypeHandle);
          end;
        end;
      end;
      if not Assigned(Result) then
        Result := _TClass.Create(ATypeHandle);
    end;
    MetaTypeMap.Add(ATypeHandle, Result);
  end;
end;