Здравствуйте, Igor Trofimov, Вы писали:
iT>То есть имеется метатип DataSetType. У него есть статическое виртуальное свойство TableCount.
iT>1) "реализация" может быть примерно такая:
iT>
iT>abstract class DataSet // это базовый тип
iT>{
iT> static virtual int TableCount { get; }
iT>}
iT>class CustomerDataSet : DataSet // это конкретный потомок
iT>{
iT> static override int TableCount { return 10; }
iT>}
iT>
Нет слов. Т.е. ты предлагаешь вместо автоматического формирования метаинформации о типе создавать его вручную? Глупее ничего не видел.
Ну, тогда нет пробем выбрости свой virtual и будет тоже самое. virtual здесь никаким боком не упал.
iT>По-моему это гораздо проще, написано на более высоком уровне, тут нет рефлекшена и нет атрибутов. Пишется в терминах модели предметной области, а не в терминах абстрактных типов.
Что касается высоты уровня, то это проблема проффесианолизма. Любой грамотный программист сделает себе функцию или класс инкапсулирующие нужные ему действия. А вот вбивать вручную информацию которая формируется автоматический — это натуральный лам.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код.
Именно. В общем, метаклассы дельфи — это выход из ситуации который избрал Борланд. Чем-то хорший, чем-то плохой. В дотнете свои подходы. Ничем не худшие. Они просто другие. Так что еще раз приходим к выводу — на лицо неумение группы бывших дельфистов спокойно принимать другие технологии. В простонародье — это называется привычками и стереотипами. Так что проблема не в языках, а в головах.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не так. new в С++-подобных языках это оператор. Считай внешная функция. Конструктор же это всегда метод. Просто у Страуструпа в определенный момент проснулась неудержимая забота о программисте и он решил защитить его от ошибок в отдельно взятом случае. Так сказать спас нас от граблей. Причем — это привело к куче других граблей. Не виртуальность конструктора это еще фигня. А вот не виртуальность виртуального деструктора — это еще та песьня. На эти грабли наступает половина программистов. Вторая просто читает о них на форума (орлов заучивших стандарт наизусть в рассчет не берем, ибо мало их). В Шарпе кострукторы и финалайзеры могут быть виртуальными. Это конечно потенциально опасно, но за-то совершенно логично. Я еще ни разу не встречал случаев наступания на эти грабли. А язык от этого получается концептуально стройным.
В форуме по С++ мы как то обсуждали эту проблему, и я предложил полноценное решение. Разбивать конструкторы и деструкторы на Before и After. Тогда можно будет иметь и место где перед уничтожением/созданием экземпляра можно произвести витруальный вызов (в полнос соотвествии с ОО-концепциями), и место строгих-пре(под)-действий.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
AVK>>Ты никак не хочешь понять одну простую вещь — обращение к метаданным много миллионов раз, неважно откуда с полным их перечитыванием это ошибка дизайна.
S> Это ты не понимаешь. Я уже устал тебе перечислять все варианты.
А что мне твои варианты? Это варианты внутри тобой разработанного дизайна. Если такое вылазит и нормально решить проблему никак значит надо искать проблемы в дизайне. Если дизайн нормален то там не должно быть обращения к одним и тем же данным много миллионов раз, особенно если это метаданные. Явный оверхед.
S> И прежде всего это связано с неопределенным типом объектов, но имеющих единую иерархию. В том, что добиться полной типизации невозможно хоть с этим ты согласен ????
Согласен. Хуже того — полной типизации невозможно добиться и в Дельфовом варианте. Вот кстати интересно — а дженерик атрибуты допустимы?
S>>> Обычно все данные связанные с классом тянут на объект увеличивая его размер, но увиличивая скорость доступа.
AVK>>Не знаю, я таких решений что то не встречал. Обычно это в твоем коде?
S> А ну да
Здравствуйте, Igor Trofimov, Вы писали:
iT>То есть имеется метатип DataSetType. У него есть статическое виртуальное свойство TableCount.
iT>1) "реализация" может быть примерно такая:
iT>
iT>abstract class DataSet // это базовый тип
iT>{
iT> static virtual int TableCount { get; }
iT>}
iT>class CustomerDataSet : DataSet // это конкретный потомок
iT>{
iT> static override int TableCount { return 10; }
iT>}
iT>
Нет слов. Т.е. ты предлагаешь вместо автоматического формирования метаинформации о типе создавать его вручную? Глупее ничего не видел.
Ну, тогда нет пробем выбрости свой virtual и будет тоже самое. virtual здесь никаким боком не упал.
iT>По-моему это гораздо проще, написано на более высоком уровне, тут нет рефлекшена и нет атрибутов. Пишется в терминах модели предметной области, а не в терминах абстрактных типов.
Что касается высоты уровня, то это проблема проффесианолизма. Любой грамотный программист сделает себе функцию или класс инкапсулирующие нужные ему действия. А вот вбивать вручную информацию которая формируется автоматический — это натуральный лам.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код.
Именно. В общем, метаклассы дельфи — это выход из ситуации который избрал Борланд. Чем-то хорший, чем-то плохой. В дотнете свои подходы. Ничем не худшие. Они просто другие. Так что еще раз приходим к выводу — на лицо неумение группы бывших дельфистов спокойно принимать другие технологии. В простонародье — это называется привычками и стереотипами. Так что проблема не в языках, а в головах.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не так. new в С++-подобных языках это оператор. Считай внешная функция. Конструктор же это всегда метод. Просто у Страуструпа в определенный момент проснулась неудержимая забота о программисте и он решил защитить его от ошибок в отдельно взятом случае. Так сказать спас нас от граблей. Причем — это привело к куче других граблей. Не виртуальность конструктора это еще фигня. А вот не виртуальность виртуального деструктора — это еще та песьня. На эти грабли наступает половина программистов. Вторая просто читает о них на форума (орлов заучивших стандарт наизусть в рассчет не берем, ибо мало их). В Шарпе кострукторы и финалайзеры могут быть виртуальными. Это конечно потенциально опасно, но за-то совершенно логично. Я еще ни разу не встречал случаев наступания на эти грабли. А язык от этого получается концептуально стройным.
В форуме по С++ мы как то обсуждали эту проблему, и я предложил полноценное решение. Разбивать конструкторы и деструкторы на Before и After. Тогда можно будет иметь и место где перед уничтожением/созданием экземпляра можно произвести витруальный вызов (в полнос соотвествии с ОО-концепциями), и место строгих-пре(под)-действий.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код.
VD>Именно. В общем, метаклассы дельфи — это выход из ситуации который избрал Борланд. Чем-то хорший, чем-то плохой. В дотнете свои подходы. Ничем не худшие. Они просто другие. Так что еще раз приходим к выводу — на лицо неумение группы бывших дельфистов спокойно принимать другие технологии. В простонародье — это называется привычками и стереотипами. Так что проблема не в языках, а в головах.
Да разговор вобщето не о Delphi. Там как раз нельзя хранить данные класса в метаклассе.
Тоесть есть иерархия классов у которых структура данных одинакова но по содержимому разная. Причем доступ к этим данным должен быть быстрым.
Виртуальные метаклассы вполне способны решить эту проблему причем ссылка на него должна быть в VMT. А так либо массив либо хэш таблица ассоциированная с типом. А насчет подходов, то I.. T... уже устал доказывать все плюсы и минусы.
Будет хорошо. Не будет тоже.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Нет, я хочу сказать что когда мы имеем задачу в целом то оказывается что никакой выгоды от метаклассов практически нет. В Дельфи все тоже красиво на бумаге, а вот когда смотрим на реализацию и внешние условия то все становится далеко не так шоколадно.
S>Если Type расширить до метакласса то все получится шоколадно.
Ничего шоколадног не получится. Ты как этот Type получать собираешься? typeof? Смысла никакого нет. object.GetType()? Но он же нетипизированный, а значит результат ничем не лучше атрибутов. Assembly.GetTypes — та же фигня? Type.GetType() — и тут тоже самое. Метаклассы не избавляют от приведения, они их выносят в другое место.
S> Посмотрим как на эту проблему, а может не проблему отреагируют создатели.
Я тебе сразу скажу — никак.
S>Если будет то удобно, если нет то и сишники безболезненно живут до сих пор,
Ну я бы не сказал что безболезненно.
S> хотя и они признают полезность метаклассов, виртуальных статических методов и данных.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, s.ts, Вы писали:
ST>>так ?
VD>Не так. new в С++-подобных языках это оператор. Считай внешная функция.
но его можно перегрузить для класса
VD>Конструктор же это всегда метод. Просто у Страуструпа в определенный момент проснулась неудержимая забота о программисте и он решил защитить его от ошибок в отдельно взятом случае. Так сказать спас нас от граблей. Причем — это привело к куче других граблей. Не виртуальность конструктора это еще фигня. А вот не виртуальность виртуального деструктора — это еще та песьня.
что это такое (не виртуальность виртуального деструктора) ?
это ты про то, как виртуальные методы из деструктора вызываются ?
VD>Вторая просто читает о них на форума (орлов заучивших стандарт наизусть в рассчет не берем, ибо мало их). В Шарпе кострукторы и финалайзеры могут быть виртуальными. Это конечно потенциально опасно, но за-то совершенно логично. Я еще ни разу не встречал случаев наступания на эти грабли. А язык от этого получается концептуально стройным.
а как реализуются виртуальные конструкторы в шарпе ?
это уже интересно
(имхо оттуда пол-шага до сабжа)
VD>В форуме по С++ мы как то обсуждали эту проблему, и я предложил полноценное решение. Разбивать конструкторы и деструкторы на Before и After. Тогда можно будет иметь и место где перед уничтожением/созданием экземпляра можно произвести витруальный вызов (в полнос соотвествии с ОО-концепциями), и место строгих-пре(под)-действий.
ну, это уже перебор
вызов inherited из нужного места проще воспринимается
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Нет, я хочу сказать что когда мы имеем задачу в целом то оказывается что никакой выгоды от метаклассов практически нет. В Дельфи все тоже красиво на бумаге, а вот когда смотрим на реализацию и внешние условия то все становится далеко не так шоколадно.
S>>Если Type расширить до метакласса то все получится шоколадно.
AVK>Ничего шоколадног не получится. Ты как этот Type получать собираешься? typeof? Смысла никакого нет. object.GetType()? Но он же нетипизированный, а значит результат ничем не лучше атрибутов. Assembly.GetTypes — та же фигня? Type.GetType() — и тут тоже самое. Метаклассы не избавляют от приведения, они их выносят в другое место.
Если объект наследник от базового типа, то приводится он к базовому типу метакласса.
А вот все его методы и данные будут конкретного класса. Так кстати и в Delphi, но только к методам. S>> Посмотрим как на эту проблему, а может не проблему отреагируют создатели.
AVK>Я тебе сразу скажу — никак.
Я бы сказал процентов на 90%. Досадно, но ладно. Просто подход с метакласссами просто красив, а в некоторых случаях и очень полезен. S>>Если будет то удобно, если нет то и сишники безболезненно живут до сих пор,
AVK>Ну я бы не сказал что безболезненно.
S>> хотя и они признают полезность метаклассов, виртуальных статических методов и данных.
AVK>Вот именно что признают.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, s.ts, Вы писали:
ST>как можно попроще реализовать статические виртуальные методы для класса (не городя фабрик и т.п.) на С# ? ST>поделитесь плз. у кого какие идеи по этому поводу ?
Никак ST>вообще как это должно выглядеть по-нормальному ?
По-нормальному, вот такому коду на Delphi
type
TBase = class
constructor Create(param: integer); virtual;
class function A: integer; virtual;
function B: integer; virtual;
end;
TBaseClass = class of TBase;
TDerived = class(TBase);
constructor Create(param: integer); override;
class function A: integer; override;
function B: integer; override;
end;
соответстует примерно такой код на C#:
class Base
{
public virtual int B() {...};
public Base(int param) {...};
}
class BaseClass
{
public static BaseClass _bc { get {...}}
public virtual Base Create(int param) { return new Base(param);}
public virtual int A() { }
}
class Derived : Base
{
public Derived(param) {...};
public override int B() {...};
}
class DerivedClass : BaseClass
{
public static DerivedClass _dc {get {}}
public override Base Create(int param) { return new Derived(param);}
public override int A() {...};
}
тогда вот такой код на Delphi:
var
ClassVar: TBaseClass;
ObjectVar: TBase;
begin
ClassVar:= TBase;
ObjectVar:= ClassVar.Create(ClassVar.A);
ClassVar:= TDerived;
ObjectVar:= ClassVar.Create(ObjectVar.B);
Разница, которую преодолеть в рамках .Net пока нельзя, состоит в следующем: 1. Во всех фабриках метод Create имеет один и тот же набор параметров. Это означает, что и тип возвращаемого значения у него всегда фиксирован. Поэтому вот такой код на C# невозможен:
var
ObjectVar: TDerived;
begin
ObjectVar = TDerived.Create(0);
К счастью, виртуальных класс-методов это не касается. 2. Тело метода Create для всех потомков Base известно совершенно точно. В С# его придется писать руками, что чревато ошибками (особенно с учетом Cut'n'paste). Дженерики, насколько мне известно, ситуацию не спасут. 3. Вот так навскидку следующий код:
function GetSome(TBase o): integer;
begin
result:= o.B+o.A;
end;
я на C# перевести затрудняюсь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
AVK>Ну то есть из рефлекшена. В таком разе про типобезопасность и производительность можно забыть, все равно ковыряться в метаданных и явно приводить придется. Тут как — сказал а, говори б. Если мы имеем возможность виртуальности метаданных значит мы должны иметь и типизированный способ получения этих типов, так ведь?
Не согласен с тем, что "сказал а — говори б". Все-таки источников данных все-таки есть три:
* явная сслка на конкретный тип
* вытаскивание типа из экземпляра
* все остальное, пожалуй можно отнести к рефлекшену.
Понимаешь, если выбирать между (10% рефлекшена + 90% не-рефлекшена) и (100% рефлекшена), то я выберу первое.
И другому посоветую, потому что 90% кода будет лучше. Это тоже плюс. Производительность — это же не беременность
AVK>Ну вполне возможно что в каких то случаях да. Вопрос только в каких. Это я и пытаюсь выяснить, а вы упорно приводите решения частных задач. Вот к примеру нафига мне знать количество таблиц в типизированном датасете, если практически наверняка я буду писать механику для любых датасетов. Соответственно я не могу полагаться на то что эта информация общая для всего типа.
Я не очень понял насчет "механики для любых датасетов". Но пример с датасетами я привел не совсем от балды — я недавно использовал большое кол-во строго типизированных потомков DataTable с общим корнем. Была нужна как раз общая статическая информация — маппинг на базу, ассоциации с другими классами, информация о колонках.
Делал атрибутами. И хорошо представляю, что это такое. Причем эту информацию действительно не всегда можно было получить из экземпляра. Вот тут у меня руки и чесались использовать виртуальные статические члены с этой метаинформацией.
AVK>Я ведь не зря привел PG. Это задачка очень широко использующая метаданные. Там есть очень много возможных применений метаинформации. ВОт и скажи мне — какую часть всей этой механики можно было бы упростить при наличии статических виртуальных методов.
С PG пример тебе на руку, потому что он работает с принципиально разнотипными объектами
Давай, если уж захотелось поговорить о том, как можно было бы переделать стандартные вещи, рассмотрим другое -перечисления например.
Хочу я перечислить например KnownColors или узнать элемент по названию:
foreach (KnownColors c in Enum.GetValues(typeof(KnownColors)))
Console.WriteLine(c);
...
KnownColors c = Enum.GetName(typeof(KnownColors), "Aqua")
Как это могло бы быть замечательно переписано?
foreach (KnownColors c in KnownColors)
Console.WriteLine(c);
...
KnownColors c = KnownColors["Aqua"]
По-моему это уже неплохо! Хотя и требует static IEnumerable. На досуге еще поищу — как чего можно было бы переписать — просто для иллюстрации.
iT>>Да, атрибутами можно сделать гибче. Но далеко не всегда проще, удобнее, быстрее и надежнее. И что жаль, что такого механизма нет в clr — он бы никому не помешал, а только помог бы.
AVK>Знаешь, в clr много чего есть. Всегда следует рассматривать обе стороны монеты. Не только полезные но и вредные. И почему кстати останавливаться именно на этом уровне? Как только мы вводим типизированные варианты метаклассов (а ты, помнится, еще и интерфейсы предлагал) то сразу появится необходимость метаинформации об этих самых метаклассах. И так до бесконечности можно раскручиваться. По мне так куда логичнее не мешать ООП модель и метаданные, а сделать их перпендикулярными друг другу, т.е. метаданные описывают ООП модель, но при этом не являются ее частью. Если задуматься то эта мысль является реинкарнацией идеи об отделении контента от представления.
Ну, естественно, до абсурда доводить не стоит. Просто, ИМХО, существующая модель — это не два, а полтора измерения Одно — экземпляры, а половинка — типы Средствами языка обратиться виртуально к члену экземпляра — можно, а к члену типа — нельзя.
AVK>В данном случае нет, так как вопрос не в еще одной конструкции, а в концептуальном изменении языка.
Я не уверен на 100%, что понимаю все последствия (вот, страуструп тоже не понимал, к чему приведут шаблоны ) но мне кажется, что изменения были бы не так уж и серьезны. Обратная совместимость — практически полная — typeof() возвращает потомка System.Type, а значит, он ведет себя как System.Type, но на самом деле это SomeAncestorType : SomeParentType : System.Type.
iT>>Или тебе необходимо именно обоснование, почему нужна статическая виртуальная информация о типе? AVK>Нет, мне нужно обоснование почему она при этом должна являться частью той же самой ООП модели что и собственно классы.
Да просто потому что это вытекает из того, что уже есть. ИМХО. конечно, но все-таки она вытекает!
AVK>Можно, но при этом компилятору пришлось бы создавать экземпляры атрибутов в процессе компиляции.
Ммм.. а AttributeUsage он анализирует на более низком уровне compiler magic, да?
Ну что-ж, согласен. Тут особый случай — это компилятор разбирает.
Ну вон, там выше про enum есть, может еще чего интересненькое придумаю — скажу
