Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:

А>>Это оффлайновый клиент. Как ему еще работать?

VD>Гы. Голлеги.



А>>Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

VD>Но это же не значит, что ее нельзя создать?

Может и можно. Но в .net у них явно не получилось.

Здравствуйте, VladD2, Вы писали:

AVK>>Им надо начинать править не с этого, а с добавления пользовательских value-типов в язык.
VD>Ну, это по большому счету не обязательно. Один фиг вэлью-типы как они есть в дотнете из концепции вырываются.

В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные

Здравствуйте, VladD2, Вы писали:

VD>Но это же не значит, что ее нельзя создать?

Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.

Ну, да. Ты под ним понимаешь того убогого урода что есть в С++ и для С++ который по своей природе тяготеет к монолитности. А АВК говорит о рефлекшоне который по сравнению с ртти, как Феррари и трехколесный велосипед.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:

На том, что я тебе могу два своих грида показать хоть сейчас. А ты можешь?

ГВ>Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.

Жаль мне тебя. Это уже синдром Рыбинкина.

ГВ>Ещё круче. Это-то зачем? Обычного SysListView32 вполне хватит.

А. Ну-ну. Вот такие смелые и затягивают приметивные проекты на полугодия.

ГВ>My God! Да почему?!

По жизни.

Сходство между нами в том, что и ты и я прошли через разработку на плюсах (а возможно и на сях). А, разница между нам в том, что я уже попробовал новые компонентные технологи, а ты пытаешся цепляться за старье обеждая себя и других в том, что все новое — это фигня и кроме проблем и неудобств ничего не дает. Общего мы зяка не найдем. По крайней мере пока ты не вникнеш в компонентный подход. Возможно тебе он и не нужен. Возможно в твоей работе старого подхода хватает за глаза. Но это не значит, что все должны цепляться за старое любой ценой.

ГВ>В данном случае — пока скорее так, чем не так.

В данном случае кому-то влом посмотреть на новое и он ищет любые аргменты чтобы этого не далеть.

Здравствуйте, desperado_gmbh, Вы писали:

_>Если говорить про ado.net, то они есть в DataReader, который проектировался для максимальной производительности.

Гы. Значит датасет проектировался для максимальных тормозов? Класная логика.

_> С точки зрения надежности и статической типизации Row.AsInt(col1) ничем не лучше Row.GetValue(col1).ToInt() — и там и там при неправильном типе будет ошибка выполнения.

Я как бы этим занимался по этому погу обяснить, что может дать такой подход...

Для начала Row.GetValue(col1).ToInt() небывает. Бывает (int)Row[col1].

Приведение типа работает очень просто. Если в обжекте не инт, то все идут лесом. AsInt может делать более разумное преобразование.

Ну, а главное соображение — это производительность. Дело в том, что сам датасет хранит данные очнь компактно и совершенно без боксинга. А при их возврате клиенту производится боксинг и анбоксинг. В общем дурь. Если же будут типизированные гет-еры и сет-еры, то лишних телодвижений не будет.

Здравствуйте, desperado_gmbh, Вы писали:

_>Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.

Речь идет не о перед скобками. А о вообще без скобок.

Здравствуйте, VladD2, Вы писали:

_>>Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.
VD>Речь идет не о перед скобками. А о вообще без скобок.

void f()
try
{
    printf("try\n");
}
catch(...)
{
}

Код соответствует стандарту.

Здравствуйте, <Аноним>, Вы писали:

А>Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.

Почему не плучается? Я лично не вижу предпосылок к этому.

Здравствуйте, <Аноним>, Вы писали:

А>Может и можно. Но в .net у них явно не получилось.

Да уж. Ну, да ладно еали они не поправят, то мы им поможем.

Здравствуйте, desperado_gmbh, Вы писали:

_>В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные

Ну, без него никуда.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:

А>>Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.

VD>Почему не плучается? Я лично не вижу предпосылок к этому.

Ну, у тебя идея была замечательная. Надеюсь получится.

Здравствуйте, VladD2, Вы писали:

VD>Для начала Row.GetValue(col1).ToInt() небывает. Бывает (int)Row[col1].
VD>Приведение типа работает очень просто. Если в обжекте не инт, то все идут лесом. AsInt может делать более разумное преобразование.

Convert.ToInt32(Row[col1])

Типизированные вызовы с более разумным преобразованием тоже должны были бы либо делать такой же Convert, либо какой-нибудь оптимизированный switch по TypeCode. Все это при желании делается простой клиентской оберткой и к ADO.NET прямого отношения не имеет.

VD>Ну, а главное соображение — это производительность. Дело в том, что сам датасет хранит данные очнь компактно и совершенно без боксинга. А при их возврате клиенту производится боксинг и анбоксинг. В общем дурь. Если же будут типизированные гет-еры и сет-еры, то лишних телодвижений не будет.

Все равно компактное хранение делается в DataStorage и боксинг происходит уже внутри — при вызове объектом DataColumn метода DataStorage, а из DataColumn данные берет DataRow. Типизированные методы пришлось бы вставлять во все эти классы, что усложняет поддержку. К тому же DataTable не завязана на типы данных IDataReader, компактное хранение — просто оптимизация для часто употребляемых типов.

Здравствуйте, VladD2, Вы писали:

_>>В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные
VD>Ну, без него никуда.

А вот комбинация из двух интов (Point, скажем) в джаве уже обязана лежать в куче. Чем она хуже простого инта?

Здравствуйте, desperado_gmbh, Вы писали:

_>

_>void f()
_>try
_>{
_>    printf("try\n");
_>}
_>catch(...)
_>{
_>}
_>

_>Код соответствует стандарту.

И какова цель? Что же тогда какой нибудь if не присобачили? И эти люди говорят о не последовательности Шарпа.

Здравствуйте, IT, Вы писали:

ГВ>>>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?

IT>>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.

ГВ>>Хммм... похоже, ты меня совсем не понял.

IT>Возможно, скорее всего ты имел ввиду рефлекшин, а не сериализацию. Правильно?

Нет. Я имел ввиду подход, уповающий на то, что в результате анализа неизвестного типа (т.е. — использования rtti) гарантированно будет выбрана (сгенерирована, проэмиччена и т.п., соль и перец по вкусу) корректная реализация алгоритма, его обрабатывающего. Подход этот я назвал "RTTI-Based". Понятно?

Здравствуйте, AndrewVK, Вы писали:

IT>>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.

ГВ>>Хммм... похоже, ты меня совсем не понял.

AVK>Правильно он тебя понял. Нет там никакого специального механизма для сериализации, есть только рефлекшен, который ровно так же пригоден и для той же визуализации, о которой ты поминал. Сему пример тот же PropertyGrid.

Не-а. Не понял. О деталях .Net я ничего говорить не собирался.

Здравствуйте, VladD2, Вы писали:

_>>void f()
_>>try
_>>{
VD>И какова цель? Что же тогда какой нибудь if не присобачили? И эти люди говорят о не последовательности Шарпа.

Цель — дать возможность обработать исключения при инициализации базовых классов. А раз уж появился такой синтаксис, почему он должен быть специфичным для конструкторов?

Здравствуйте, VladD2, Вы писали:

ГВ>>Хммм... похоже, ты меня совсем не понял.

VD>Нет. Это ты нас не понимашь. И по всей видимости не попробовав рефлекшон прочувтвовать всей его мощи нелья.

Кто о чём...

Здравствуйте, desperado_gmbh, Вы писали:

_>Типизированные вызовы с более разумным преобразованием тоже должны были бы либо делать такой же Convert, либо какой-нибудь оптимизированный switch по TypeCode.

Именно.

_>Все это при желании делается простой клиентской оберткой и к ADO.NET прямого отношения не имеет.

Делается, то делается, но эффективность не та. Да и проблемы могут возникнуть. Ведь может оказаться, что для ускорения процесса нажно обратиться к закрытым данным, ан нет тебе.

_>Все равно компактное хранение делается в DataStorage и боксинг происходит уже внутри — при вызове объектом DataColumn метода DataStorage, а из DataColumn данные берет DataRow. Типизированные методы пришлось бы вставлять во все эти классы, что усложняет поддержку.

Дык я говорю, что при грамотной реализации баксинга можно было избежать. Не согласен?

_>К тому же DataTable не завязана на типы данных IDataReader, компактное хранение — просто оптимизация для часто употребляемых типов.

А причем тут ридер? Я тебе объясняю что дает применение типизированных методов доуступа. А ты мне про Ерему. Дизайн кривоват у датасета...