Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, s.ts, Вы писали:
ST>>визитор работает с инстанциями и не накладывает ограничений на отношения объектов (имеется ввиду контроль того, что объекты из одной ветки иерархии классов). ST>>мне это все больше напоминает абстрактную фабрику.
VD>Подходы разные бывают.
ST>>кстати, вопрос о виртуальном конструкторе не ввергает всех в шок?
VD>Меня нет. Даже не оборот.
ST>>а ведь он [конструктор] тоже в некотором смысле статический метод.
каюсь, тут, наверное, я тоже на дельфи съехал — там он действительно в нек. смысле статичен
(TMyClass.Create)
VD>Не прийми за наезд, но сдается мне, что все же кроме Дельфи ты все же не изучил как следует других языков. Уж больно твои суждения всегда не нее сваливаются.
изучил, изучил. но это знание из дешевых, так что... что сейчас вижу — о том пою...
м.быть мои суждения и сваливаются на делфи.
я же говорил уже чем последние полтора года занимаюсь ?
там еще беда с терминологией. у борланд-классов есть 3 типа методов:
1.статические
2.виртуальные
3.методы класса
статические — это то, что в сях называется member-ами
виртуальные — то же самое что и везде
методы класса — в сях называется статическими
я в свое время переучивался, чтобы на одном языке с коллегами говорить. теперь, видать, обратно придется
а вам, в свете миграции дельфистов на дотнет, видать, придется изучить и ту терминологию, чтобы флейма, аналогичного этому топику, было поменьше
ST>>p.s. вопрос тут более абстрактен, чем дельфи vs... также долго можно спорить о том, как должны виртуальные функции из конструктора вызываться или о чем-то другом и это уже не будет delphi vs...
VD>Я не очень понимаю как связаны эти вопросы. Но четко вижу, что сам вопрос вам до лампочки. Вам просто не нравится, что сделано не так как в Дельфи.
нет. все наоборот.
мне нравится как это сделано в дельфи, но я не знаю как сделано в дотнете и поэтому задаю вопросы
ничего, что я так откровенно ?
еще мне нравится, что там (в дельфи) из конструктора виртуальные методы вызываются не как обычные мемберы (в терминологии дельфи их нужно было бы назвать статическими ). больше там ничего интересного имхо нету (ну, м.б. вызов inherited конструкторов/деструкторов в произвольном месте, но это уже не критично)
ST>>на всякий случай повторюсь, что меня интересовала возможность реализации схожей функциональности в дотнете, а не споры о "нужно/не нужно"
VD>Еще раз повторю, если бы тебя это интересовало бы, то ты бы обяснил каких целей хочешь добиться, а не искал бы экзотических фич дельфи в совершенно другом по иделологии продукте.
что самое удивительное, Igor Trofimov и Serginio1 сразу поняли что я имел ввиду.
видимо, и вопрос к ним был, а не к тебе.
кстати, по тем веткам, где предприняты попытки объяснить, видно, что это бесполезно, т.к. сводится к "зачем"
я для себя сабж выяснил
а флейм все множится
вообще можно жить очень без многого, даже без классов и объектов, которые, в общем-то тоже как "синтаксический сахар" (вспомним, что на некоторых платформах до сих пор C++ — это препроцессор в C )
M>>Всё-таки быстро 10 млн объектов создавать или нет, ты как-то определись. Хорошо — создавай, плохо — не создавай. S> А вот как ты считаешь как организована десериализация объектов в Юкон????
Ну только не говори, что они на каждый объект они свой тип создают.
AVK>Два вопроса:
AVK>1) Ты не привел реализацию TableCount AVK>2) Откуда берется ссылка на тип?
Как сам понимаешь, я это писал при условии, что статические виртуалы и метаклассы есть.
Отвечаю в обратном порядке (так понятнее будет)
2) ссылку на тип я беру, как и Vlad просто из конкретного типа (для простоты) и затем привожу к типу метакласса:
(DataSetType)typeof(CustomersDataSet)
То есть имеется метатип DataSetType. У него есть статическое виртуальное свойство TableCount.
1) "реализация" может быть примерно такая:
abstract class DataSet // это базовый тип
{
static virtual int TableCount { get; }
}
class CustomerDataSet : DataSet // это конкретный потомок
{
static override int TableCount { return 10; }
}
По-моему это гораздо проще, написано на более высоком уровне, тут нет рефлекшена и нет атрибутов. Пишется в терминах модели предметной области, а не в терминах абстрактных типов.
Здравствуйте, mihailik, Вы писали:
M>>>Всё-таки быстро 10 млн объектов создавать или нет, ты как-то определись. Хорошо — создавай, плохо — не создавай. S>> А вот как ты считаешь как организована десериализация объектов в Юкон????
M>Ну только не говори, что они на каждый объект они свой тип создают.
Здравствуйте, Igor Trofimov, Вы писали:
iT>2) ссылку на тип я беру, как и Vlad просто из конкретного типа (для простоты) и затем привожу к типу метакласса: iT>
iT>(DataSetType)typeof(CustomersDataSet)
iT>
Я так и думал. В таком разе все твои виртуальные методы превращаются в идиотизм, поскольку ничем не лучше КонкретныйТип.TableCount.
iT>class CustomerDataSet : DataSet // это конкретный потомок iT>{ iT> static override int TableCount { return 10; } iT>}
10 откуда? От балды?
iT>По-моему это гораздо проще, написано на более высоком уровне, тут нет рефлекшена и нет атрибутов. Пишется в терминах модели предметной области, а не в терминах абстрактных типов.
Пока что твой код абсолютно бессмысленен с практической точки зрения.
iT>>и чего — по-прежнему первый вариант ничуть не сложнее, не меее надежен, не менее производителен?
AVK>Два вопроса:
AVK>1) Ты не привел реализацию TableCount AVK>2) Откуда берется ссылка на тип?
Дельфевый вариант, если TableCount
Class Function TableCount:Integer; virtual;
данной записи выглядит так
CustomersDataSet.TableCount;
Получение метакласса из объекта.
Function DataSetTypeTableCount(V:Object):Integer;
Begin
result:=DataSetType(V.ClassType).TableCount
end;
По поводу атрибутов, то если часто к ним обращаться и не кэщировать толку от них мало.
Так как Attribute.GetCustomAttribute не очень быстрая.
Статические виртуальные методы ускоряют получение информации, хотя в Net реализации приходится лезть в хэш таблицу для получения метакласса ассоциированного с типом в хэш таблицу, но это все равно во много раз быстрее чем Attribute.GetCustomAttribute.
Если же тип известен или то вызов метода метакласса идет на прямую.
Можно рассматривать атрибуты как статическую не изменяемую информацию связанной с типом.
В метаклассах такой зависимости нет.
Можно рассматривать метаклассы и атрибуты по аналогии как абстрактные классы и интерфейсы.
Если же ссылку на метакласс прописывать в VMT так же как и для Type то затраты на получение
метакласса минимальны, а информации ассоциированной с данным классом можно прописать сколько угодно, и очень удобный доступ к ней.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mihailik, Вы писали:
M>>>Всё-таки быстро 10 млн объектов создавать или нет, ты как-то определись. Хорошо — создавай, плохо — не создавай. S>> А вот как ты считаешь как организована десериализация объектов в Юкон????
M>Ну только не говори, что они на каждый объект они свой тип создают.
А вообще о чем разговор. При чем здесь тип.
Речь идет о том, что если у меня тип заранее известен, то я считываю данные прямо в объект предварительно один раз создав.
Если же поле у меня неопределенного типа, то по полю TypeID я должен найти конструктор этого типа
передать ему ID объекта, что бы он загрузил данные.
В данном случае разговор идет, что я с TypeID ассоциирую метакласс, а мне говорт что лучше Type
Но при этом с использовать метакласс намного удобнее быстрее и типизированно чем Type.
Еще не понял?????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Дельфевый вариант, если TableCount S>Class Function TableCount:Integer; virtual; S> данной записи выглядит так S>CustomersDataSet.TableCount;
Это не реализация, это декларация.
S>Получение метакласса из объекта. S>Function DataSetTypeTableCount(V:Object):Integer; S> Begin S>result:=DataSetType(V.ClassType).TableCount S> end;
Это мы уже видели.
S>По поводу атрибутов, то если часто к ним обращаться и не кэщировать толку от них мало.
А что мешает кешировать?
S> Статические виртуальные методы ускоряют получение информации, хотя в Net реализации приходится лезть в хэш таблицу для получения метакласса ассоциированного с типом в хэш таблицу, но это все равно во много раз быстрее чем Attribute.GetCustomAttribute.
Ну да. А если в Дельфи получать метаинформацию путем парсинга исходников то будет еще медленнее.
S> Можно рассматривать атрибуты как статическую не изменяемую информацию связанной с типом. S>В метаклассах такой зависимости нет.
Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код.
AVK> Я так и думал. В таком разе все твои виртуальные методы превращаются в идиотизм, поскольку ничем не лучше КонкретныйТип.TableCount.
Конечно. Просто я делал по аналдогии с примером Vlad'а, чтобы было понятнее.
Естественно, в реальном коде это была бы ссылка на тип, преданная в параметре, например:
Так понятнее вся мощь и выразительность? И попробуй сунуть в этот метод typeof(Int32)! И не надо проверять — есть атрибут, нет его, есть ли он в предке... и сколько их есть, если не дай бог, несколько можно.
AVK>10 откуда? От балды?
Оттуда же, откуда ты написал бы атрибут DataTableCountAttribute со значением 10. Конкретный тип знает это про себя.
VariantDataSet : DataSet может, впрочем, считать это и как-то по-другому, например, как Влад нарисовал.
Полиморфность остается — я все равнот смогу обратиться через простое свойство.
iT>>По-моему это гораздо проще, написано на более высоком уровне, тут нет рефлекшена и нет атрибутов. Пишется в терминах модели предметной области, а не в терминах абстрактных типов.
AVK>Пока что твой код абсолютно бессмысленен с практической точки зрения.
Ну это же пример. Ты всегда критикуешь за практическую неприменимость примеры подходов?
S>>По поводу атрибутов, то если часто к ним обращаться и не кэщировать толку от них мало.
AVK>А что мешает кешировать?
Зачем тогда атрибуты, если для каждой иерархии классов я могу и так создать хэштаблицу данных и прописывать в нее нужные данные для каждого типа в конструкторе типа, причем без всяких ограничений на определении конструктора,полей и свойств атрибутного типа итд.
S>> Статические виртуальные методы ускоряют получение информации, хотя в Net реализации приходится лезть в хэш таблицу для получения метакласса ассоциированного с типом в хэш таблицу, но это все равно во много раз быстрее чем Attribute.GetCustomAttribute.
AVK>Ну да. А если в Дельфи получать метаинформацию путем парсинга исходников то будет еще медленнее.
Да только эта информация кэшируется автоматом и не надо производить лишних действий.
S>> Можно рассматривать атрибуты как статическую не изменяемую информацию связанной с типом. S>>В метаклассах такой зависимости нет.
AVK>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код.
Атрибут это класс, но опять же, без кэширования в нем мало толку, а с кэшированием смотри выше.
и солнце б утром не вставало, когда бы не было меня
Это не ответ. Откуда изначально возьмется эта ссылка?
iT>Так понятнее вся мощь и выразительность? И попробуй сунуть в этот метод typeof(Int32)! И не надо проверять — есть атрибут, нет его, есть ли он в предке... и сколько их есть, если не дай бог, несколько можно.
Зато я могу прикрутить сколь угодно много параллельных механик.
AVK>>Пока что твой код абсолютно бессмысленен с практической точки зрения.
iT>) Ну это же пример. Ты всегда критикуешь за практическую неприменимость примеры подходов?
Тебя просили задачу, а ты привел бессмысленный с практической точки зрения код.
Здравствуйте, Serginio1, Вы писали:
AVK>>А что мешает кешировать? S> Зачем тогда атрибуты, если для каждой иерархии классов я могу и так создать хэштаблицу данных и прописывать в нее нужные данные для каждого типа в конструкторе типа, причем без всяких ограничений на определении конструктора,полей и свойств атрибутного типа итд.
Очень просто — кеширование делается в библиотеке, а атрибуты прописывает пользователь.
AVK>>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код. S> Атрибут это класс, но опять же, без кэширования в нем мало толку,
В нем достаточно толку. Я тебе уже писал — производительность в случае анализа метаданных некритична, поскольку самих метаданных мало. Если ты не можешь построить алгоритм так чтобы он не перечитывал миллионы раз одну и ту же информацию то это твои проблемы, а не проблемы языка. И кеширование это один из возможных способов этого избежать, но далеко не единственный.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>А что мешает кешировать? S>> Зачем тогда атрибуты, если для каждой иерархии классов я могу и так создать хэштаблицу данных и прописывать в нее нужные данные для каждого типа в конструкторе типа, причем без всяких ограничений на определении конструктора,полей и свойств атрибутного типа итд.
AVK>Очень просто — кеширование делается в библиотеке, а атрибуты прописывает пользователь.
Ага я же изготовитель я же и пользователей. AVK>>>Нет там никакой разницы. Есть данные, которые в обеих случаях неизменны и есть код. Атрибут тоже может содержать код. S>> Атрибут это класс, но опять же, без кэширования в нем мало толку,
AVK>В нем достаточно толку. Я тебе уже писал — производительность в случае анализа метаданных некритична, поскольку самих метаданных мало. Если ты не можешь построить алгоритм так чтобы он не перечитывал миллионы раз одну и ту же информацию то это твои проблемы, а не проблемы языка. И кеширование это один из возможных способов этого избежать, но далеко не единственный.
Опять об одном и томже. Есть данные касающиеся только класса, а есть данные экземпляра класса.
Причем данные в иерархии классов по структуре одинаковы, но данные разные.
И в этом случае она должна разделяться. И доступ как к данным объекта так и данным класса должна быть быстрый и синтаксически простой. При чем доступ из объекта как к своим данным так и к данным класса.
Обычно все данные связанные с классом тянут на объект увеличивая его размер, но увиличивая скорость доступа. Метаданные как раз могут решить проблему грамотного разделения данных и скорость доступа и типизацию.
Кстати не ответил на ограничения в атрибутах????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>В нем достаточно толку. Я тебе уже писал — производительность в случае анализа метаданных некритична, поскольку самих метаданных мало. Если ты не можешь построить алгоритм так чтобы он не перечитывал миллионы раз одну и ту же информацию то это твои проблемы, а не проблемы языка. И кеширование это один из возможных способов этого избежать, но далеко не единственный.
S> Опять об одном и томже. Есть данные касающиеся только класса, а есть данные экземпляра класса. S> Причем данные в иерархии классов по структуре одинаковы, но данные разные.
Тогда это уже не метаданные и статические виртуальные методы уж точно не годятся. Тут обычные виртуальные.
S> И в этом случае она должна разделяться. И доступ как к данным объекта так и данным класса должна быть быстрый и синтаксически простой. При чем доступ из объекта как к своим данным так и к данным класса.
Ты никак не хочешь понять одну простую вещь — обращение к метаданным много миллионов раз, неважно откуда с полным их перечитыванием это ошибка дизайна.
S> Обычно все данные связанные с классом тянут на объект увеличивая его размер, но увиличивая скорость доступа.
Не знаю, я таких решений что то не встречал. Обычно это в твоем коде?
S>Метаданные как раз могут решить проблему грамотного разделения данных и скорость доступа и типизацию. S> Кстати не ответил на ограничения в атрибутах????
AVK>Это не ответ. Откуда изначально возьмется эта ссылка?
Да откуда угодно. Например, при перечислении всех типов — потомков DataSet. Или из настройки/из БД.
Если ты хочешь мне сказать, что раз там уже знают конкретный тип, то значит, там точно знают число таблиц, то будешь неправ. Я тогда по аналогии могу сказать про виртуальные методы экземпляра — изначально объект где-то создается, там точно знают конкретный тип, вот путь и вызывают SaveCustomer() вместо virtual Save().
iT>>Так понятнее вся мощь и выразительность? И попробуй сунуть в этот метод typeof(Int32)! И не надо проверять — есть атрибут, нет его, есть ли он в предке... и сколько их есть, если не дай бог, несколько можно.
AVK>Зато я могу прикрутить сколь угодно много параллельных механик.
Да я согласен, что это не панацея Я просто утверждаю, что в каких-то случаях это реально полезная концепция, стройная и естественным образом вытакающая из возможности хоть как-то работать с типами.
Да, атрибутами можно сделать гибче. Но далеко не всегда проще, удобнее, быстрее и надежнее. И что жаль, что такого механизма нет в clr — он бы никому не помешал, а только помог бы.
iT>>) Ну это же пример. Ты всегда критикуешь за практическую неприменимость примеры подходов? AVK>Тебя просили задачу, а ты привел бессмысленный с практической точки зрения код.
Я фигею — для объяснения преимуществ foreach ты тоже не ограничишься пятью строками, а будешь брать целую практическую задачу? неужели недостаточно того, что мы рассмотрели, чтобы понять, где плюсы, где минусы?
Или тебе необходимо именно обоснование, почему нужна статическая виртуальная информация о типе? Тогда возьми любое место, где применяются атрибуты и найдешь там парочку таких мест, где по логике это статическая виртуальная информация.
Например, AttributeUsageAttribute. У любого атрибута эта информация должна быть. Она статична. Доступ полиморфный. То есть можно было бы написать
class Attribute
{
public abstract AttributeTargets Targets {get;}
public abstract bool Inherited {get;}
public abstract bool AllowMultiple {get;}
}
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>В нем достаточно толку. Я тебе уже писал — производительность в случае анализа метаданных некритична, поскольку самих метаданных мало. Если ты не можешь построить алгоритм так чтобы он не перечитывал миллионы раз одну и ту же информацию то это твои проблемы, а не проблемы языка. И кеширование это один из возможных способов этого избежать, но далеко не единственный.
S>> Опять об одном и томже. Есть данные касающиеся только класса, а есть данные экземпляра класса. S>> Причем данные в иерархии классов по структуре одинаковы, но данные разные.
AVK>Тогда это уже не метаданные и статические виртуальные методы уж точно не годятся. Тут обычные виртуальные.
S>> И в этом случае она должна разделяться. И доступ как к данным объекта так и данным класса должна быть быстрый и синтаксически простой. При чем доступ из объекта как к своим данным так и к данным класса.
AVK>Ты никак не хочешь понять одну простую вещь — обращение к метаданным много миллионов раз, неважно откуда с полным их перечитыванием это ошибка дизайна.
Это ты не понимаешь. Я уже устал тебе перечислять все варианты. И прежде всего это связано с неопределенным типом объектов, но имеющих единую иерархию. В том, что добиться полной типизации невозможно хоть с этим ты согласен ???? И разумеется S>> Обычно все данные связанные с классом тянут на объект увеличивая его размер, но увиличивая скорость доступа.
AVK>Не знаю, я таких решений что то не встречал. Обычно это в твоем коде?
А ну да берем DataStorage
поля type и dbNullBits это информация класса, а она внедряется в объект.
Методы
public override object DefaultValue { get; }
и поля
defaultValue
defaultValueAsObject
итд.
Это информация класса, и через статические виртуальные методы она легко получается.
Но это примитивы. А когда аналог DataStorage являются более сложные объекты то ...
S>>Метаданные как раз могут решить проблему грамотного разделения данных и скорость доступа и типизацию. S>> Кстати не ответил на ограничения в атрибутах????
AVK>Какие?
Если еонкретно, допустимый набор типов данных ограничивается типами премитивов а также String, Type, Object. Кроме того, можно использовать одномерные массивы этих типов с осчетом от нуля.
Но не мне тебе объяснять.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Igor Trofimov, Вы писали:
iT>Да откуда угодно. Например, при перечислении всех типов — потомков DataSet. Или из настройки/из БД.
Ну то есть из рефлекшена. В таком разе про типобезопасность и производительность можно забыть, все равно ковыряться в метаданных и явно приводить придется. Тут как — сказал а, говори б. Если мы имеем возможность виртуальности метаданных значит мы должны иметь и типизированный способ получения этих типов, так ведь?
iT>Если ты хочешь мне сказать, что раз там уже знают конкретный тип, то значит, там точно знают число таблиц, то будешь неправ.
Нет, я хочу сказать что когда мы имеем задачу в целом то оказывается что никакой выгоды от метаклассов практически нет. В Дельфи все тоже красиво на бумаге, а вот когда смотрим на реализацию и внешние условия то все становится далеко не так шоколадно.
AVK>>Зато я могу прикрутить сколь угодно много параллельных механик.
iT>Да я согласен, что это не панацея Я просто утверждаю, что в каких-то случаях это реально полезная концепция, стройная и естественным образом вытакающая из возможности хоть как-то работать с типами.
Ну вполне возможно что в каких то случаях да. Вопрос только в каких. Это я и пытаюсь выяснить, а вы упорно приводите решения частных задач. Вот к примеру нафига мне знать количество таблиц в типизированном датасете, если практически наверняка я буду писать механику для любых датасетов. Соответственно я не могу полагаться на то что эта информация общая для всего типа. Я ведь не зря привел PG. Это задачка очень широко использующая метаданные. Там есть очень много возможных применений метаинформации. ВОт и скажи мне — какую часть всей этой механики можно было бы упростить при наличии статических виртуальных методов.
iT>Да, атрибутами можно сделать гибче. Но далеко не всегда проще, удобнее, быстрее и надежнее. И что жаль, что такого механизма нет в clr — он бы никому не помешал, а только помог бы.
Знаешь, в clr много чего есть. Всегда следует рассматривать обе стороны монеты. Не только полезные но и вредные. И почему кстати останавливаться именно на этом уровне? Как только мы вводим типизированные варианты метаклассов (а ты, помнится, еще и интерфейсы предлагал) то сразу появится необходимость метаинформации об этих самых метаклассах. И так до бесконечности можно раскручиваться. По мне так куда логичнее не мешать ООП модель и метаданные, а сделать их перпендикулярными друг другу, т.е. метаданные описывают ООП модель, но при этом не являются ее частью. Если задуматься то эта мысль является реинкарнацией идеи об отделении контента от представления.
AVK>>Тебя просили задачу, а ты привел бессмысленный с практической точки зрения код.
iT>Я фигею — для объяснения преимуществ foreach ты тоже не ограничишься пятью строками, а будешь брать целую практическую задачу? неужели недостаточно того, что мы рассмотрели, чтобы понять, где плюсы, где минусы?
В данном случае нет, так как вопрос не в еще одной конструкции, а в концептуальном изменении языка.
iT>Или тебе необходимо именно обоснование, почему нужна статическая виртуальная информация о типе?
Нет, мне нужно обоснование почему она при этом должна являться частью той же самой ООП модели что и собственно классы.
iT>Например, AttributeUsageAttribute. У любого атрибута эта информация должна быть. Она статична. Доступ полиморфный. То есть можно было бы написать
iT>
iT>class Attribute
iT>{
iT> public abstract AttributeTargets Targets {get;}
iT> public abstract bool Inherited {get;}
iT> public abstract bool AllowMultiple {get;}
iT>}
iT>
Можно, но при этом компилятору пришлось бы создавать экземпляры атрибутов в процессе компиляции.
AVK>Нет, я хочу сказать что когда мы имеем задачу в целом то оказывается что никакой выгоды от метаклассов практически нет. В Дельфи все тоже красиво на бумаге, а вот когда смотрим на реализацию и внешние условия то все становится далеко не так шоколадно.
Если Type расширить до метакласса то все получится шоколадно. Даже не расширяя а просто добавляя как вспомогательный класс аналог Type, но со ссылкой в VMT. А метакласс ничем от обычного класса как и Type не отличается.
Посмотрим как на эту проблему, а может не проблему отреагируют создатели.
Если будет то удобно, если нет то и сишники безболезненно живут до сих пор, хотя и они признают полезность метаклассов, виртуальных статических методов и данных.
и солнце б утром не вставало, когда бы не было меня
). больше там ничего интересного имхо нету (ну, м.б. вызов inherited конструкторов/деструкторов в произвольном месте, но это уже не критично)
Я так и думал. В таком разе все твои виртуальные методы превращаются в идиотизм, поскольку ничем не лучше КонкретныйТип.TableCount.
