VD>Ну, тогда нет пробем выбрости свой virtual и будет тоже самое. virtual здесь никаким боком не упал.
Ну, ты просто все-таки не въехал
Без virtual это работать никак не будет А точнее, будет работать только со ссылкой на конкретный тип, а не на абстрактный.
Здравствуйте, mihailik, Вы писали:
S>>Но при этом с использовать метакласс намного удобнее быстрее и типизированно чем Type.
M>Ну и замечательно. Я бы тоже так делал в некоторых случаях. Согласен.
M>Но зачем ты хотел на каждый объект создавать отдельный экземпляр этого самого метакласса — не вдупляю ну никак
Я такого не говорил. А говорил только о создании объекта из метакласса, а не из Type или делегатов из за неизвестности типа, но по какомуто внутреннему TypeID в БД можно создать массив или хэш таблицу метаклассов ассоциируемую с конкретным TypeID. Так как метаклассы уже созданы то мне легче засунуть туда их и создавать оттуда объекты.
А созданий объектов может доходить и до десятков миллионов. Только и всего.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Митона не знаю. Знаю только что это махровый интерпретатор с никакой производительностью по сарвению с компилируемыми средами.
VD>Так что еще раз приходим к выводу — на лицо неумение группы бывших дельфистов спокойно принимать другие технологии.
Ты знаешь — я бы не ввязался в спор, если бы перед этим не накушался атрибутами по самое нехочу. То есть я "принял" технологию и старался ее использовать там, где она нужна — для расширения метаданных. И понял, что это далеко не так вкусно, как вы тут описываете. Один атрибут — да. Два — пожалуй. Десять, которые нужны в нескольких местах — и начинается убогое копирование кода. Естественно, был написан helper для извлечения атрибутов — иначе кода было бы еще в три раза больше. Но кардинально ситуацию он не исправляет.
Извини, но я хочу вместо
TableCountAttribute tca = (TableCountAttribute)AttributeHelper.GetSingleAttribute(dataSetType, typeof(TableCountAttribute));
if (tca == null)
throw new MetadataException("Attribute TableCountAttribute not found");
return tca.TableCount;
писать просто
return dataSetType.TableCount;
и не хотеть этого меня врядли кто-то заставит.
Увы, но заявления о том, что настоящие кул-программеры предпочтут первый вариант я тоже за серьезные принять не могу
да, правда, не подумал. "Ошарпился" вконец. первая строка гораздо проще должна быть.
Никаких typeof. iT>>
iT>>tableCount = AnyDataSetType.TableCount;
iT>>
Это наглядно показывает, как опыт тесного общения с языком, в котором отсутствуют какие-то возможности, корректирует наше мышление таким образом, что мы эти возможности перестаем воспринимать, мы их не замечаем, обходимся без них и потом кричим "нафиг надо?".
Здравствуйте, mihailik, Вы писали:
M>>>Ну только не говори, что они на каждый объект они свой тип создают.
ST>>а м.б. на каждый тип свой объект ?
M>Это как раз нормально, Type и есть один объект на тип.
M>А Serginio почему-то хочет ещё и типы создавать почаще. Или я его не понял. Или он сам не знает чего хочет.
Вот именно что не понял. Я как раз не хочу создавать метаклассы, а из них создавать объекти типа ассоциированных с этим метаклассом.
Еще раз. Есть БД. Есть классы ассоциированные с талицей (ми). Есть поля которые могут иметь неопределенный тип. Для них поле имеет вид
struct HerEgoZnaetType
{
int TypeID;
int ID;
}
По TypeID я должен найти соответствующий класс вызвать конструктор, передать ID что бы он загрузил данные из БД.
В Delphi это решается просто.
Есть базовый класс, и есть классы порожденные от него.
TBDClass= class ob TBDClasses;
Я строю массив TBDClass[] DB, или DB: Array of TBDClass; и прописываю значения этих метаклассов
Например
BD[0]=СправочникНоменклатура;
BD[1]=ДокументПриходнаяНакладная;
итд
И если мне надо создать объект
То object:=bd[TypeId].Create(ID)
Может еще поподробнее объяснить?????
и солнце б утром не вставало, когда бы не было меня
S> Еще раз. Есть БД. Есть классы ассоциированные с талицей (ми). Есть поля которые могут иметь неопределенный тип. Для них поле имеет вид S>struct HerEgoZnaetType S>{ S> int TypeID; S> int ID; S>}
Очень хорошо понял. Отлично, и на C# и на Дельфи это делается легко, фабрики классов.
Просто в Дельфи эта функциональность встроена в язык, но чтобы это было чем-то сверхгениальным или сверхнеобходимым так нет.
Здравствуйте, mihailik, Вы писали:
S>> Еще раз. Есть БД. Есть классы ассоциированные с талицей (ми). Есть поля которые могут иметь неопределенный тип. Для них поле имеет вид S>>struct HerEgoZnaetType S>>{ S>> int TypeID; S>> int ID; S>>}
M>Очень хорошо понял. Отлично, и на C# и на Дельфи это делается легко, фабрики классов.
M>Просто в Дельфи эта функциональность встроена в язык, но чтобы это было чем-то сверхгениальным или сверхнеобходимым так нет.
А как насчет спицфиских данных о типе??? Я получаю не только объект, но данные класса. Иногда и конструктор вызывать не надо, а просто получить данные но очень быстро через виртуальные статические методы (наверное в 20 раз повторюсь но еще желательно и данные в Delphi этого нет, вернее можно через методы получить некоторые заранее инициализированные переменные или массив статические данные, т.к. структура одинакова, но данные разные, но это неудобно хотелось бы что бы они хранились в самом метаклассе), т.к. наследуются они от одного предка . Да и фабрику классов делать абсолютно нет никакого желания, 400 классов.
Все можно сделать, только в одних случаях это намного удобнее и красивее.
и солнце б утром не вставало, когда бы не было меня
S> Иногда и конструктор вызывать не надо, а просто получить данные но очень быстро через
Но почему обязательно "через"?
Ты хочешь получить данные по ID типа — ну так и получай и храни их по ID. Это будет раза в два быстрее, чем лепить тип, вызывать эту самодельную виртуальность.
В общем, я думаю, мы друг друга поняли. Статическая виртуальность сама по себе интересная фича, но в C# её нет и это нормально. Гуд?
Здравствуйте, mihailik, Вы писали:
S>> Иногда и конструктор вызывать не надо, а просто получить данные но очень быстро через
M>Но почему обязательно "через"?
M>Ты хочешь получить данные по ID типа — ну так и получай и храни их по ID. Это будет раза в два быстрее, чем лепить тип, вызывать эту самодельную виртуальность.
А ее и лепить не надо. Нашел метакласс а там и данные и конструкторы. Очень удобно.
И почему это Type виртуальный??? M>В общем, я думаю, мы друг друга поняли. Статическая виртуальность сама по себе интересная фича, но в C# её нет и это нормально. Гуд?
Может и введут в Net, а от Дельфевой реализации прок есть, но очень маленький от того как возможно. Еще не вечер. Хотя и вероятность этого очень очень мала.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Igor Trofimov, Вы писали:
VD>>Ну, тогда нет пробем выбрости свой virtual и будет тоже самое. virtual здесь никаким боком не упал.
iT>Ну, ты просто все-таки не въехал iT>Без virtual это работать никак не будет А точнее, будет работать только со ссылкой на конкретный тип, а не на абстрактный.
Объясни, что тебе здесь дает виртуальность?
abstract class DataSet // это базовый тип
{
static virtual int TableCount { get; }
}
class CustomerDataSet : DataSet // это конкретный потомок
{
static override int TableCount { return 10; }
}
Чтобы это имело какой-то смысл, то нужно чтобы под DataSet как-то мог скрываться CustomerDataSet, и при вызове DataSet.TableCount реально происходил вызов CustomerDataSet.TableCount. Но я не представляю себе как под DataSet может скрываться CustomerDataSet, а ты себе это как представляешь?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Ты никак не хочешь понять одну простую вещь — обращение к метаданным много миллионов раз, неважно откуда с полным их перечитыванием это ошибка дизайна.
S>> Это ты не понимаешь. Я уже устал тебе перечислять все варианты.
AVK>А что мне твои варианты? Это варианты внутри тобой разработанного дизайна. Если такое вылазит и нормально решить проблему никак значит надо искать проблемы в дизайне. Если дизайн нормален то там не должно быть обращения к одним и тем же данным много миллионов раз, особенно если это метаданные. Явный оверхед.
Ну ты глупостей то не говори. Весь нет на боксинге и унбоксинге построен, а Type это тот же метакласс только сильно усеченный. Плохой дизайн??? Согласен.
И дженерики не во всем помогут. Так в любом случае при типе поля object или базового класса деваться некуда .
S>> И прежде всего это связано с неопределенным типом объектов, но имеющих единую иерархию. В том, что добиться полной типизации невозможно хоть с этим ты согласен ????
AVK>Согласен. Хуже того — полной типизации невозможно добиться и в Дельфовом варианте. Вот кстати интересно — а дженерик атрибуты допустимы?
Надо будет посмотреть. S>>>> Обычно все данные связанные с классом тянут на объект увеличивая его размер, но увиличивая скорость доступа.
AVK>>>Не знаю, я таких решений что то не встречал. Обычно это в твоем коде?
S>> А ну да
AVK>Ну тогда это не обычно, а у тебя
Не уменя а у M$. Ты помоему что то опустил????
и солнце б утром не вставало, когда бы не было меня
U>Чтобы это имело какой-то смысл, то нужно чтобы под DataSet как-то мог скрываться CustomerDataSet, и при вызове DataSet.TableCount реально происходил вызов CustomerDataSet.TableCount. Но я не представляю себе как под DataSet может скрываться CustomerDataSet, а ты себе это как представляешь?
Вот по-видимому, много кто не представляет. И очень зря.
Как у тебя под ссылкой на экземпляр DataSet скрывается экземпляр CustomerDataSet, так и под ссылкой на тип DataSet может скрываться тип CustomerDataSet. Все просто.
Здравствуйте, Igor Trofimov, Вы писали:
U>>Чтобы это имело какой-то смысл, то нужно чтобы под DataSet как-то мог скрываться CustomerDataSet, и при вызове DataSet.TableCount реально происходил вызов CustomerDataSet.TableCount. Но я не представляю себе как под DataSet может скрываться CustomerDataSet, а ты себе это как представляешь?
iT>Вот по-видимому, много кто не представляет. И очень зря.
iT>Как у тебя под ссылкой на экземпляр DataSet скрывается экземпляр CustomerDataSet, так и под ссылкой на тип DataSet может скрываться тип CustomerDataSet. Все просто.
iT>>Как у тебя под ссылкой на экземпляр DataSet скрывается экземпляр CustomerDataSet, так и под ссылкой на тип DataSet может скрываться тип CustomerDataSet. Все просто.
U>А синтаксис этого скрытия какой?
Ты о чем? В шарпе этого нету, так что гипотетически синтаксис подобной штуки может быть любой.
Здравствуйте, Igor Trofimov, Вы писали:
iT>>>Как у тебя под ссылкой на экземпляр DataSet скрывается экземпляр CustomerDataSet, так и под ссылкой на тип DataSet может скрываться тип CustomerDataSet. Все просто.
U>>А синтаксис этого скрытия какой?
iT>Ты о чем? В шарпе этого нету, так что гипотетически синтаксис подобной штуки может быть любой.
Дык ты и напиши свой вариант гипотетического синтаксиса.
U>Дык ты и напиши свой вариант гипотетического синтаксиса.
Собственно, изменение в синтаксисе нужно только одно — для объявления ссылки на некоторый подтип.
При том, C# старается использовать все по месту и нигде не объявлять типы отдельно от определения, то Delphi-вариант с предварительным объявлением "type DataSetType = class of DataSet;" не очень подходит.
Может как-нибудь так DoSomething(typeof(DataSet) t) ?
физически это транслировалось бы в DoSomething(DataSetType t), где DataSetType потомок Type.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Собственно, изменение в синтаксисе нужно только одно — для объявления ссылки на некоторый подтип.
iT>При том, C# старается использовать все по месту и нигде не объявлять типы отдельно от определения, то Delphi-вариант с предварительным объявлением "type DataSetType = class of DataSet;" не очень подходит.
iT>Может как-нибудь так DoSomething(typeof(DataSet) t) ?
iT>физически это транслировалось бы в DoSomething(DataSetType t), где DataSetType потомок Type.
Наконец-то понял, как это можно использовать. В принципе довольно красивая фича, хотя сомневаюсь, что шибко нужная.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Ну, ты просто все-таки не въехал iT>Без virtual это работать никак не будет А точнее, будет работать только со ссылкой на конкретный тип, а не на абстрактный.
А как у абстрактного типа могут быть конкретные метаданные? Или у нас количество таблиц неотемлемая часть любого класса?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
