Здравствуйте IVaNС, Вы писали:
IVNС>Влад, это я с тобой общался в виде Анонима. IVNС>Скажи вашему программеру сайта, чтоб реализовал заполнение имени и пароля из кукисов, а то люди забывают вписаться
Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. Так, что общайся с IT сам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Аноним, Вы писали:
SS>>А хотелось бы что то наподобии:
SS>>
SS>>Type type= ...GetTypes....
SS>>runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать
А>Можно создать экземпляр объекта с вызовом конструктора с помощью Activator.CreateInstance(Type _Type, object[] param)
А>param - параметры конструктора (выбирается подходящий)
SS>>obj.Method(param);
SS>>
А>Так не получится — не скомпиляется.
obj.Method(param); — Я имел ввиду, если поддержку на уровне языка сделать.
А> Но вот типа такого — реально: А>obj.Methods["Method"](param);
Да наверное можно сделать класс оболочку более менее юзабельную не меняя языка, если еще использовать передачу переменного числа параметров
А>Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять А>Достаточно написать класс, который расковыривает в реатайме любой тип.
Жалко в библиотеке нет такого класса, каждый теперь будет пользоваться самоделками.
Re[10]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Аноним, Вы писали:
А>Чтобы компилятор делал перемап, надо его изменить :) А если менять, так уже лучше добавить множ. наследование
Во-первых, агрегация круче. Она в рантайме пашет. Правда, медленнее, но не на столько, чтобы обратно возвращаться к геморрою с множественным наследованием. Думаю агрегации и шаблонов будет достаточно.
К тому же, множественное наследование не поддерживается CLR-ом. И это принципиально. Им нужен единый корень. Причем на этом базируется куча системных кусков. Так, что можно ждать только сделать только эмуляцию в виде раскрутки наследования, но при этом все равно корень будет один и вся множественность будет всего лишь удобством для реализации интерфейсов. Реальное МН видимо так и останется только в С++.
А>По-моему, это тупиковый путь. во-первых, отсутствуют проверки на этапе компиляции.
Это ж почему? На этапе компиляции будет проверяться, что агрегируемый класс реализует интерфейс. Этого более чем достаточно.
А>Во-вторых, атрибуты придется разгребать в реалтайме и на основании этого генерить код.
Ничего в рантайме генерировать не придется. Все решается очень просто. Почти как в COM. У агрегируемого объекта подменяется функции привидения типов. В следствии чего появляется возможность приводить указатель на интерфейс реализуемый агрегируемым объектом к указателю на агрегирующий объект. Далее так же модифицируется приведение типов у агрегирующего объекта и при попытке привести его к указателю на интерфейс реализуемый внешним объектом берется указатель на него и возвращается вместо своего. Любая попытка привести (изменить) указатель на интерфейс должна проходить через агрегирующий объект. При этом все неверные приведения должны пресекаться на корню.
Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).
Атрибуты как раз и нужны компилятору, чтобы автоматически реализовать эту схему, т.е. создать код приведения и подсовывания.
А> Это жутко геморройно и некрасиво, а ведь наша задача — получить красивую реализацию !
Что геморройно? Что некрасиво?
А>Уж лучше использовать обычную агрегацию, так хоть, напремер, не вызовешь метод, которого нет :) — не скомпиляется.
Оооочень интересно, что ты понимаешь под "обычной агрегацией"? Ана была только в COM. Причем именно там она была геморроем еще тем. Тут же предлагается стройная идеология. Пара строчек кода и ты подключаешь готовую реализацию интерфейса. Да еще вдобавок можно делать это на лету (в рантайме).
SS>> Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.
Вот тогда перед каждым таким вызовом нужно ставить идентификатор вроде "dinamic", а то в VB6 половину кода пишется таким образом. Но, там хоть в этом нужда есть. Ведь там это единственный простой способ сделать полиморфизм. И то лучше интерфейсами обходится, если можно.
Иначе обычная лень будет приводить к куче рантайм-ошибок. :(
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Silver_s, Вы писали:
SS>Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.
Подводные камни один черт появятся. А пока что приходится колупаться в надводных, так как любой интерфейс ручками реализовывать приходится.
SS>Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса, которая еще не известна во время компиляции
Так. Еще разок. Не функция, а интерфейс. Улавливаешь разницу?
SS> (неизвестно даже виртуальные там методы или нет)
В интерфейсах все функции по поределению виртуальные. Более того у каждого класса свой vtbl строится. Так что при подключении реализации или просто целиком подменяется втбл агрегирующего класса, или копируются указатели на методы.
SS>, здесь прийдется попыхтеть чтобы реализовать без глюков.
Хотел бы я видеть задачу которую можно не пыхтя без глюков реализовать.
SS> Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.
А тут ничего не меняется. Если класс унаследован от агригирующего класса (в прочем как и от обычного), то он получит свой втбл и нужно только обеспечить, что если объект не перебивает метод, при подключении реализации чтобы или делать временный втбл копируя туда все что нужно, или придумать иную идеологи вызова методов из базового втбл-а.
Вот примерная картина втбл-ов:
Интерфейс Агрегирующий Агрегриуемый Наследник
класс класс
f1 = 0 - f1 -
f2 = 0 - f2 f2
В конце концов придется создавать динамический втбл и копировать туда указатели на методы. Можно вообще запритить переопределение у таких классов и переопределять методы у агрегируемых объектов. Короче, есть над чем подумать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).
Задача нормально реализуемая в одну сторону. В том же COM (CoCreateInstance) есть pUnkOuter — указатель на агрегирующий объект, пока непонятно куда его запихать агрегируемому объекту. Хотя можно на это забить, автоматического преобразования в одну сторону к интерфейсам членов класса было бы уже достаточно для большинства задач. Возможно будут проблемы со всякими неоднозначностями типа когда два члена класса реализуют один и тот же интерфейс, но это можно было бы регилировать параметрами атрибутов.
VD>Атрибуты как раз и нужны компилятору, чтобы автоматически реализовать эту схему, т.е. создать код приведения и подсовывания.
В данном случае можно вполне обойтись ключевым словом. Возможно, это даже лучше, т.к. ключевые слова понимаются только компилятором на этапе компиляции, а атрибуты должны восприниматься любыми языками. Т.е. в случае с атрибутами существует проблема совместимости.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>А вот я думаю, что в большинстве случаев sealed ускорения не даст.
The sealed modifier is primarily used to prevent unintended derivation,
but it also enables certain run-time optimizations. In particular,
because a sealed class is known to never have any derived classes,
it is possible to transform virtual function member invocations on
sealed class instances into non-virtual invocations.
А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?
Здравствуйте Аноним, Вы писали:
А>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
А как же его методы AddXXX?
Здравствуйте IT, Вы писали:
IT>Возможно будут проблемы со всякими неоднозначностями типа когда два члена класса реализуют один и тот же интерфейс, но это можно было бы регилировать параметрами атрибутов.
Так компилятор и должен проверять такие вещи. Описал двойную реализацию, будь добр совершить пешую прогулку с эротическим уклоном.
VD>>Атрибуты как раз и нужны компилятору, чтобы автоматически реализовать эту схему, т.е. создать код приведения и подсовывания.
IT>В данном случае можно вполне обойтись ключевым словом. Возможно, это даже лучше, т.к. ключевые слова понимаются только компилятором на этапе компиляции, а атрибуты должны восприниматься любыми языками. Т.е. в случае с атрибутами существует проблема совместимости.
Здесть не все так однозначно. Лучше подумать еще. Дело в том, что информация о типах все равно нужно, а так как это надстройка над CLR, то без атрибутов информация о агрегации просто исчезнет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>>>Атрибуты как раз и нужны компилятору, чтобы автоматически реализовать эту схему, т.е. создать код приведения и подсовывания.
IT>>В данном случае можно вполне обойтись ключевым словом. Возможно, это даже лучше, т.к. ключевые слова понимаются только компилятором на этапе компиляции, а атрибуты должны восприниматься любыми языками. Т.е. в случае с атрибутами существует проблема совместимости.
VD>Здесть не все так однозначно. Лучше подумать еще. Дело в том, что информация о типах все равно нужно, а так как это надстройка над CLR, то без атрибутов информация о агрегации просто исчезнет.
Я думаю, что компилятор должен сгенерировать соответствующий код, в этом случае атрибуты не нужны.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте VladD2, Вы писали:
VD>>А вот я думаю, что в большинстве случаев sealed ускорения не даст.
AVK>The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.
Недадо код для цитат использовать! Текст при этом не переностится.
Ну, а по делу... Кто-нибудь эксперементировал? Я почти уверен, чно этот сэйлед ничего не даст супратив обычных методов. Возможно если объявить сэйледом виртуальную функцию, то что-нибудь и выйдет, но тоже сомнительно.
AVK>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?
А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.
Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто. Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать.
Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте IT, Вы писали:
VD>>Здесть не все так однозначно. Лучше подумать еще. Дело в том, что информация о типах все равно нужно, а так как это надстройка над CLR, то без атрибутов информация о агрегации просто исчезнет.
IT>Я думаю, что компилятор должен сгенерировать соответствующий код, в этом случае атрибуты не нужны.
А как ты себе видишь описание этого? Метоинформацию? Так по атрибутам можно будет спокайно понять, что имеет место агрегация, а ключевое слово будет выкинуто в прщессе компиляции (она же не CLR-ное).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
IT>>Я думаю, что компилятор должен сгенерировать соответствующий код, в этом случае атрибуты не нужны.
VD>А как ты себе видишь описание этого? Метоинформацию? Так по атрибутам можно будет спокайно понять, что имеет место агрегация, а ключевое слово будет выкинуто в прщессе компиляции (она же не CLR-ное).
В случае с ключевым словом необходимо будет наделить объект каким-нибудь виртуальным методом (можно через интерфейс типа ICastable или IAggregatable), компилятор будет просто генерировать этот метод.
В случае с атрибутами это может быть один на всех метод, который будет прочёсывать все члены объекта и выполнять при необходимости кастинг.
Вот и думай что лучше? Я пока затрудняюсь сказать. Первый вариант будет явно производительнее, второй будет работать сразу для всего CLR, т.е. компиляторы править не надо будет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>>>А вот я думаю, что в большинстве случаев sealed ускорения не даст.
AVK>>The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.
VD>Ну, а по делу... Кто-нибудь эксперементировал? Я почти уверен, чно этот сэйлед ничего не даст супратив обычных методов. Возможно если объявить сэйледом виртуальную функцию, то что-нибудь и выйдет, но тоже сомнительно.
Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными.
AVK>>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь? VD>А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.
Ну от кривых рук защиты пока не придумали.
VD>Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто.
Мне честно говоря вся объектная модель windows.forms крайне не понравилась. Она очень похожа на VCL, но это, извините, 1992 год, а на дворе уже 2002. И это на фоне вполне передовых в этом плане частей, например того же ремоутинга.
VD> Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать. А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.
VD>Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.
Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить.
Здравствуйте AndrewVK, Вы писали:
AVK>Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными.
Дык, это разные вещи... Понятно, что если функци не виртуальная, то и работать она будтет быстрее.
AVK> А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.
Думаю, эту пролему обойти можно. Именно потому что они виндовые. Вскгда можно забраться на системный уровень и сделать все как нужно.
Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты.
AVK>Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить.
К сажалению многие лепят все что подруку попадется. А приват и вовсе сделан по умолчанию. Один налпит другой уже ничего не исправит. Была бы моя воля я по умолчанию протектед поставил.
И вообще я много читал умных книжет кде пугают тем что мол если будешь все публик делать, то проблем будет много. М вон тонну COM-объектов написали в основном весь код паблик, все равно через COM-интерфейс ничего видно не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными. VD>Дык, это разные вещи... Понятно, что если функци не виртуальная, то и работать она будтет быстрее.
Ну так sealed как раз и делает виртуальные функции статическими.
AVK>> А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.
VD>Думаю, эту пролему обойти можно. Именно потому что они виндовые. Вскгда можно забраться на системный уровень и сделать все как нужно.
Не, писать нативный код это уже не то. Нехочу.
VD>Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты.
Чем мне в свое время джава понравилась, так это тем что там возможна стандартизация сторонних библиотек. Не люблю сторонних вещей. Как показывает опыт еще по Дельфи 99.9% их весьма посредственного качества.
AVK>>Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить. VD>К сажалению многие лепят все что подруку попадется.
А стоит ли на таких язык править?
VD>А приват и вовсе сделан по умолчанию. Один налпит другой уже ничего не исправит. Была бы моя воля я по умолчанию протектед поставил.
Приват по умолчанию правильно. А под кривые руки язык затачивать не стоит.
Здравствуйте VladD2, Вы писали:
SS>>Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса, которая еще не известна во время компиляции VD>Так. Еще разок. Не функция, а интерфейс. Улавливаешь разницу? SS>> (неизвестно даже виртуальные там методы или нет)
VD>В интерфейсах все функции по поределению виртуальные. Более того у каждого класса свой vtbl строится.
Да я чуток погорячился насчет того что при имплементации интерфейса можно делать невиртуальные функции. Просто там есть то ли глючок то ли фича, — если при имплементации метода интерфейса не указать kw virtual, то в производных классах этот метод переопределить уже нельзя никак (только new). Может это фича C# а не CLR, но это сложно назвать виртуальной функцией.
Может эту багу подправим в новом языке. Чтобы действительно все методы в интерфейсах были по умолчанию виртуал.
SS>>, здесь прийдется попыхтеть чтобы реализовать без глюков.
VD>Хотел бы я видеть задачу которую можно не пыхтя без глюков реализовать.
Я думаю сложность даже не в реализации компилятора, а в создании непротиворечивой спецификации самого стандарта языка. Так как стандарт языка вещь очень монолитная, трудно туда что-то впихнуть не нарушив остальное.
VD>В конце концов придется создавать динамический втбл и копировать туда указатели на методы. Можно вообще запритить переопределение у таких классов и переопределять методы у агрегируемых объектов. Короче, есть над чем подумать.
Наверно прийдется сделать такой класс sealed. Т.к тут проглядывается концептуальная проблема. Наследоваться надо во время compiletime и нужно уже все знать о классе, а реализация определяется
только в runtime, да еще и может меняться.
Re[12]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте VladD2, Вы писали:
VD>А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.
Угу. Уже приходилось :( :maniac:
VD>Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто. Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать. :maniac:
У меня все сильнее складывается впечатление, что непродуманность некоторых вещей заставит микрософт в новой версии библиотек сделать несовместимости со старыми :)
VD>Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.
Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !
Задача решена — УРА ! — землекопа полтора !
Re[11]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?
Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ? Это анархия какая-то, а не хваленая американськая демократия :) . Дерьмократия, я бы сказал.
Так, что общайся с IT сам.
Жалко в библиотеке нет такого класса, каждый теперь будет пользоваться самоделками.
Если нам не помогут, то мы тоже никого не пощадим.
