Здравствуйте, mihailik, Вы писали:
M>Можно-можно. Delphi.NET генерирует вполне разумный IL.
Не ясно зачем, ну да...
M>Просто это не static virtual в понимании IL. Отдельный workaround, скрытые метаклассы и т.п.
Вот видишь. Я же говорю, что этог бреда там не будет.
M>По части workaround они в Delphi хорошо поработали. Я где-то полгода назад читал, что там наворотили. Очень прикольно, ловкачи просто.
Хакреы. Ну, да их понять можно. Все это для совместимости с кодом написанным под старые версии дельфи. Со временем уйдет в небытие.
M>Жаль, что это теперь мало кому нужно.
Почему жаль?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
M>Ну, это я поясняю, что товарищу хочется. Мне после Дельфи это хорошо понятно
Дык везде свои подходы. Используя одну технологию после другой нужно четко понимать что в ней и как, а не пытаться переложить под кальку старые подходы.
Если вместо создания стройной концепции МС свалил бы в новую технологию все подходы считающиеся удобными в дугих (Дельфи, С++, Ява, ...), то получился бы винигрет от которого только лишь тошнило бы.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
M>Виртуальные статические методы в Delphi.NET присуствуют, это факт. Они, конечно, видны не как статические методы с точки зрения C#. В общем, польза от них возможна только не выходя из Дельфи.
Т.е. они не виртуальные или не статические. То-то и оно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
— она не работает. там Qt обернули своими классами и ерунда получилась. фразой "MSIL от борланд может не работать" я высказал предположение, что когда борланд обернет дотнет своими приблудами, то это может опять не работать (в буквальном смысле).
Открою тебе один сикрет... КуТи не работает сама по себе. Борлондовцы просто не знализ, что эту либу до ума напильниками нужно доводить. Вот и глючат их обпртки.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
M>>И что, в дотнете нет готового решения? S> Решить можно все и не обязательно на до нете. Но так как Type не расширяем, то дельфевые метаклассы этим как раз и занимаются. Плохо это или хорошо решать каждому индивидуму.
Про патерн (будь они не ладны) визитор слышал? Вот как раз позволяет делать вируальность налево. Может это решит проблемы дельфистов?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Не. В том то и дело. Что ну в упор не вижу поблему.
В решении указанных задачек. AVK уже отказался.
VD>С помощью этих фич ты решаешь две проблемы: 1. Получение информации о типе в рантайме. Это в дотнете делает метод GetType, причем не от илюзорного класса, а от любокго объекта ссылку на который можно получить.
Читаем выше. Информация, возвращаемая GetType слишком общая. И я хочу получать информацию о типе от ссылки на тип, а не от экземпляра.
VD>2. Динамическое создание экземпляра объекта. Это решается Activator-ом.
Ни слова не было про то, что нужно создавать эзкемпляр. Задачки не про это.
Здравствуйте, Serginio1, Вы писали:
S> Пример, есть документ у которого есть поле неопределенного типа Субкото, по Ид типа я должен создать экземпляр класса и просчитать, в следующей записи документа Субконто имеет другой тип. S>Старое значение субконто записывается в таблицу с ассоциированным с типом кэшем экземпляров типа или уничтожается.
Зачем уничтожать? Учитывая количество типов субконто и неизменность их состава в процессе работы программы спокойно можно ничего не удалять.
S> Итак далее. Но данный пример только с одним документом, на самом деле этих документов может быть много. Вся беда с неопределенными типами.
Пока не вижу никакой беды.
S> Мета классы позволяют легко создавать объекты данного типа
Чем это легче Type.CreateInstance?
S> и создавать и получать статическую информацию для данного типа.
Уже говорилось о том что атрибуты способны делать тоже самое. Да, несколько больше кода, зато значительно выше гибкость и простота использования для конечного программиста.
— она не работает. там Qt обернули своими классами и ерунда получилась. фразой "MSIL от борланд может не работать" я высказал предположение, что когда борланд обернет дотнет своими приблудами, то это может опять не работать (в буквальном смысле).
VD>Открою тебе один сикрет... КуТи не работает сама по себе. Борлондовцы просто не знализ, что эту либу до ума напильниками нужно доводить. Вот и глючат их обпртки.
там основные проблемы с синхронизацией Qt-шных объектов с их борландовскими обертками. (т.е. объект qt имеет одно состояние, а борландовский рапортует совсем о другом).
при том еще часть объектов борландовские, а часть — кутэшные.
второе — то, что qt за уши притянули к борландовской модели и до конца это нормально не сделали. в результате получается, что общаться толком с объектами можно толко посылкой сообщений (тогда кликсовые объекты лучше отрабатывают изменения через хуки), но это не согласуется с тем, как работают db-aware контролы от борланд.
третье — элементарная халатность: в комбобоксе в одном месте забыли единицу вычесть в результате не выбрать 1-й элемент выпадающего списка; TAlignment.Assign — опечатка в результате которой он не работает правильно; что-то еще было, уже не помню, сейчас уже все нужные классы своими обернуты. но этого, как мне кажется, уже достаточно для коммерческой библиотеки, продаваемой уже не первый год
это если интересует то, как все на самом деле.
по поводу qt особо плохого ничего не слышал. да и в KDE особых глюков не замечал.
Здравствуйте, mihailik, Вы писали:
M>P.S. Не, ну если в Дельфи есть — хорошо. А к C# прикручивать это фанатизм чистой воды. Такое нужно наказывать рублём
э-э-э-э, да ты тоже, я погляжу, на рубль ориентирован
iT>Никто не собирается ничего "эмулировать". Задачи, которые я приводил — вытекают не из возможностей Delphi или другого языка, где это есть, а из самой парадигмы ООП. И именно с отсутствующими возможностями они решались бы оптимальным способом, а не через задницу, как это приходится делать сейчас.
iT>Языки можно сравнивать, если они работают в некоторой общей парадигме (имхо, поэтому C# и Perl несравнимы, а C#, Delphi, Java — сравнимы).
Интересно, а кто тебе сказал, что Delphi поддерживает парадигму ООП? Или С++? Они в конце-концов реализовали её в шарпе, а Delphi и C++ — это просто языки, в которых есть такой тип данных — объект. И называть их за это объектно-ориентированными.... Ну вы, блин, даёте....
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>Про патерн (будь они не ладны) визитор слышал? Вот как раз позволяет делать вируальность налево. Может это решит проблемы дельфистов?
визитор работает с инстанциями и не накладывает ограничений на отношения объектов (имеется ввиду контроль того, что объекты из одной ветки иерархии классов).
мне это все больше напоминает абстрактную фабрику.
кстати, вопрос о виртуальном конструкторе не ввергает всех в шок?
а ведь он [конструктор] тоже в некотором смысле статический метод.
p.s. вопрос тут более абстрактен, чем дельфи vs... также долго можно спорить о том, как должны виртуальные функции из конструктора вызываться или о чем-то другом и это уже не будет delphi vs...
на всякий случай повторюсь, что меня интересовала возможность реализации схожей функциональности в дотнете, а не споры о "нужно/не нужно"
Здравствуйте, VladD2, Вы писали:
VD>Ято же касается рассуждений о других языках... то приведите хоть один кроме дельфи где были бы виртуальные метода не-инстанс-методы.
Здравствуйте, mihailik, Вы писали:
S>>И уж если говорить об ООП, нужно это или не нужно не важно, то почему Type нельзя расширять??? Чем он отличается от любого класса????
M>Ты что, вообще против значка sealed? Это же основы!
public abstract class Type : MemberInfo, _Type, IReflect
Не вижу sealed. Причем так все его виртуальные методы так или иначе перекрываются в наследниках но компилятором.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mihailik, Вы писали:
S>> Мета классы позволяют легко создавать объекты данного типа и создавать и получать статическую информацию для данного типа.
M>Что такое "данный тип"? Ты хранишь в БД название типа?
M>Если название, то задача перерождается в получение статической информации по названию типа.
Дельфевые мета слассы ассоциируются с типом, и расширяют его функционал. Единственно, что пока не нашел как создать class var virtual — виртуальные переменные класса, что лего сделать если внелрить их в мета класс
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Пример, есть документ у которого есть поле неопределенного типа Субкото, по Ид типа я должен создать экземпляр класса и просчитать, в следующей записи документа Субконто имеет другой тип. S>>Старое значение субконто записывается в таблицу с ассоциированным с типом кэшем экземпляров типа или уничтожается.
AVK>Зачем уничтожать? Учитывая количество типов субконто и неизменность их состава в процессе работы программы спокойно можно ничего не удалять.
А смысл его держать. По затратам получается как физическим так и скорости выполнения программы, что новый объект создать проще.
S>> Мета классы позволяют легко создавать объекты данного типа
AVK>Чем это легче Type.CreateInstance?
Типизированный вызов конструктора и его скорость. S>> и создавать и получать статическую информацию для данного типа.
AVK>Уже говорилось о том что атрибуты способны делать тоже самое. Да, несколько больше кода, зато значительно выше гибкость и простота использования для конечного программиста.
Атрибуты вещь хорошая, но во первых когда я конструирую класс и работа только с наследниками данного класса. Зачем нужны атрибуты. Атрибуты тоже играют роль метаклассов. И так или иначе мы крутимся вокруг них. Мало того мне не хватает еще и виртуальных переменных класса.
А с дельфевой реализацией это можно сделать, только не знаю еще как. Через атрибуты можно сделать, но не так красиво и главное быстро.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, s.ts, Вы писали:
ST>как можно попроще реализовать статические виртуальные методы для класса (не городя фабрик и т.п.) на С# ? ST>поделитесь плз. у кого какие идеи по этому поводу ?
ST>вообще как это должно выглядеть по-нормальному ?
Вы можете кричать здесь хоть до ночи, а мне не хватает виртуальных переменных классов.
И что бы вызов не через атрибуты, рефлексии итд.
и солнце б утром не вставало, когда бы не было меня