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

K>А вот и нет Мы unused юзаем.

Это попытка выпрямить кривой дизайн линзой с обратной кривизной.

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

K>Согласен. На строчку кода меньше.

Не только. Ещё на одну проверку меньше. Ты в своём варианте тоже должен будешь на null не забыть проверить. А то мало ли что?

IT wrote:

> _>А вот если описать так, как предлагаешь ты, то что будешь делать в
> ситуации http://rsdn.ru/forum/?mid=1939558

Автор: Kluev
Дата: 05.06.06

и "do_something_usefull< Face
> >()"?
> Не совсем понял в какой именно ситуации, но да ладно. Есть куча хороших
> паттернов. Можно использовать null-паттерн, можно кидать исключение.
> Выбирай.
Куча методов, возвращающих почти одно и то же, но в несколько разных видах Face, CFace, QS_Face, QF_Face. Писать кучу
геттеров — решение, но никак не группирует эти геттеры. И не позволяет манипулировать этой кучкой геттеров единообразно.

> _>а вот с родным "__declspec(property(...))" не умеет работать.
> Видимо забили.
Тут проблема в "ассемблерности" С, имхо.

> _>А что ещё полезного, но, желательно, именно для языка программирования?
> Свойства — это удобно. Например, удобно делать отложенную загрузку. Со
? Чем геттер хуже?

> свойствами хорошо работает баиндинг и куча визуальных компонент.
> Редактор контролов в студии, например, позволяет редактировать свойства
> контролов прямо в дизайн тайм. Абстолютно тот же самый редактор можно
> использовать и в рантайм. Например, на нём сделан редактор настроек в
> Янусе. Вообще, компонентное программирование слабо мыслимо без свойств.
Чем геттеры/сеттеры не устраивают?

> Например, в джаве для этого изобрели специальное соглашение — методы,
> начинающиеся с get(без параметров)/set(с одним параметром) считаются
> свойствами и также доступны всяким компонентным приблудам.
Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал, чтобы кто-то особо сокрушался по поводу их
отсутствия...
Кстати, там дальше пошли, там понятие bean ввели, более "правильное" для компонентной модели. Но зачем это включать в
язык?.. это мне не совсем кажется большой необходимостью.

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

_>Куча методов, возвращающих почти одно и то же, но в несколько разных видах Face, CFace, QS_Face, QF_Face. Писать кучу геттеров — решение, но никак не группирует эти геттеры. И не позволяет манипулировать этой кучкой геттеров единообразно.

А какая тебе манипуляция нужна?

_>? Чем геттер хуже?
_>Чем геттеры/сеттеры не устраивают?

Мы же уже выяснили. Тем что приходится писать меньше более читабельного кода. В нашем примере это соотношение было 2 раза.

_>Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал, чтобы кто-то особо сокрушался по поводу их отсутствия...

Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться об отсутствии того, чего никогда не видел и не пробовал.

_>Кстати, там дальше пошли, там понятие bean ввели, более "правильное" для компонентной модели. Но зачем это включать в язык?.. это мне не совсем кажется большой необходимостью.

Ты у них спроси сколько надо сделать приседаний и сколько раз постучать в бубен, чтобы завернуть обычный джавовский класс в бин. Потом поговорим о более "правильном".

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

IT>А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.

И это является основанием для обвинений C++ в куче грехов? Ты, как бы, не забывай о том, что есть и те, кто пользуется C++ подолгу и на одном месте, то есть, имеют такое же сугубо персональное, но прямо противоположное по содержанию мнение.

Кроме того, апеллируя к личному опыту не надо забывать, что оружие сие — обоюдоострое.

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

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

K>>>Стандарты то они конечно стандарты... но то что ты перечистил... ты почему-то видимо свято уверен, что жизни за пределами Windows не существует

VD>>Батенька, ды вы совсем дальше своего носа не видите. (с) Дотнет давно в виде Моно живет под Линуксом. Ява на таком количестве платформ, что С++ позавидует. Тут дело в том, что лично нам эти платформы просто не нужны. Ну, не занимаемся мы дешевым хостингом, где Линукс король песочнецы.

K>Сынок, хостингом я тоже не занимаюсь... ни дорогим, ни дешёвым

Мне плевать папать чем ты лично занимашся. Но если это:

K>А под Solaris или HP-UX Mono есть?

то привыкни к мысли, что ты в микроскопическом меньшинстве и мэйнстрим с индустрией слова не про тебя. Ты ремеслинник, возможно виртуозный, занимающийся далекой от народа задачей.

K>VladD2, задачи бывают разные... не только хостинг... и не только под винды... я очень удивлюсь если ты с этим не согласишся

Еще раз. Задачи бывают разные — это столь же бесспорно, как и банально. Так что про это говорить не стоит. Нас же интересуют значительные объемы применения ака мэйнстрим. Так вот значительные объемы применения Линуксов — это исключительно хостинг. По крайней мере пока... но похоже, что и вообще. Радужные прогнозы о захвате Линуксом десктопа оказались мыльным пузырем.

K>Проект в котором в настояшее время я участвую, живет на Win, Linux, Sun, HP, AIX. При разработке используеться С++, TCL, Java...

Рад за тебя. Можешь спросить у своего начальства сколько у них клиентов под Соляркой или ХаПэ. Мой прогноз — еденицы.

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

IT>>А дальше с комом в горле и скупой слезой отметил, что плюсы для моих задач, что-то пока применять не получается и по их текущему состояния вряд-ли когда-либо получится.

ГВ>И это является основанием для обвинений C++ в куче грехов?

Это является пояснением, что из-за тех самых грехов плюсам не находится места в моих задачах.

ГВ>Ты, как бы, не забывай о том, что есть и те, кто пользуется C++ подолгу и на одном месте, то есть, имеют такое же сугубо персональное, но прямо противоположное по содержанию мнение.

Да ради бога.

ГВ>Кроме того, апеллируя к личному опыту не надо забывать, что оружие сие — обоюдоострое.

Да я могу если что и вторым остриём...

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

IT>Это конечно круто защищать комитет и не знать, что двойное подчёркивание зарезервировано для разработчиков компиляторов.

Тем не менее, это не имеет никакого отношения к осмысленности выбираемый мной идентификаторов. Так что говори лучше по существу.

E>>В особенности пункт 4 вообще никаким боком к текущей задаче не относится. Если бы задача допускала порождение исключения вместо возвращения значения, исходная функция get_current не возвращала бы bool.

IT>Если ты фанат кодов возврата, то у тебя больше нет вариантов. Об исключениях ты если и будешь знать, то всё равно защищать коды возврата станешь до посинения.

Нет, я не фанат кодов возврата, но считаю, что в некоторых случаях в C++ коды возврата использовать удобнее (иногда и быстрее, и безопаснее), чем исключения.

Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.

IT>Возразить на это я могу лишь следующее. Твой bool не несёт никакой информации о том что же такого произошло и почему вызов не удался. Я ещё могу понять такие вещи как

bool int.TryParse(string s, out int n)

Здесь хотя бы понятно, что вызов Try не предполагает слишком подробной информации об ошибке и bool вполне оправдан. Но в твоём случае — это по любому кривой дизайн. Либо надо проверять на null возвращаемое значение, что вполне логично, либо кидать исключение.

IT>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.

А вдруг метод вернет указатель на не инициализированную память, но не нулевой указатель? Если мы говорим о C++, то проверка указателя на null -- это иллюзия безопасности.

Самое важное возражение против

bool get_current(Face *&)

-- это отсутствие гарантий в случае возникновения в get_current исключения. Например, get_current создал объект Face, присвоил его out-параметру, начал делать что-то еще и выбросил исключение. Тот, кто вызывал get_current() не может использовать указатель на Face, но он имеет этот указатель. И компилятор не может гарантировать, что этот указатель нигде не будет использоваться.

Это серьезный аргумент против out-параметров, но ты его не озвучил. Кроме того, он не может быть абсолютным законом. Т.к., во-первых, в проекте исключения могут вообще не использоваться. Во-вторых, сама функция может гарантировать строгую гарантию исключений (т.е., что после установки out-параметров исключения порождаться не могут). В-третьих, get_current могла иметь формат

bool get_current(Face &)

-- т.е. ей для изменения передается уже созданный кем-то объект Face. Такой вариант может использоваться, если есть серьезные требования к производительности (когда слишком накладно в get_current вызывать new), либо когда Face является вершиной иерархии наследования и в get_current на самом деле будут передаваться объекты производных от Face типов.

Тем не менее, перечисленные проблемы с гаранитией исключений не имеют отношения к понятности и читабельности кода. А именно об этом я тебя и спрашивал

Автор: eao197
Дата: 05.06.06

.

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

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

K>>А вот и нет Мы unused юзаем.
K>>

K>>struct Unused
K>>{
K>>  template <class T> operator T ()
K>>  {
K>>     static T dummy;
K>>     return dummy;
K>>  }
K>>};

K>>extern Unused unused;

K>>//=================================
K>>void test()
K>>{
K>>   if ( obj.find(foo, unused) )
K>>   {
K>>   } 
K>>}
K>>

WH>Во-первых этот код вобще должен не компилироваться ибо должно быть operator T& ().
Писал руками поэтому и ошибся. А в коде конечно же юзается T&

WH>Во-вторых даже если его исправить то с многопоточностью у нас будут проблемы в случае если T что-то болие сложное чем Some* или int.
Да ладно сказки рассказывать. Класс заточен под POD параметры:

// проеккция точки на прямую, возвращает расстояние а так же параметрию и точку проекции
double project_to_line(const Point &from, const Point &lineStart, const Point &lineEnd, double &t, Point &projection);

Вот для такихфункций и юзается:

double dist = project_to_line(from, A, B, unused, unused); // нас интересует только расстояние расстояние

WH>Итого: имеем грабли которые могут привести к рассогласованию внутреннего состояния объекта что может привести к порче памяти и/или утечке памяти в зависимости от фазы луны. Те поймать такую ошибку практически не реально.
Если юзать вещи там где они уместны и не юзать там где неуместны, то и граблей не будет никаких. А если круглое носить,а квадратное катать то грабли будут по любому, не зависимо от того какая среда опасная или безопасная.

WH>Вывод: unsafe вобще и С++ в частности тебе противопоказан.
Ха Ха Ха.

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

_>Kluev wrote:

>> можно ведь и просто current<Edge>() К томуже если я не ошибаюсь
>> глобальных функций в шарпе нет и потребуется некий класс. т.е.
>> будет еще синтаксический оверхед (tm) в виде
>> Globals.CurrentEdge. А если это все по библиотекам раскидано, то тогда
>> еще и прийдется более явно указывать:
>> Core.Globals.CurrentEdge, etc
_>Тормозишь, причём тут глобальные переменные? Он говорит, мол, круто, если CurrentEdge будет пропертей.

Так ведь функции (get_current) глобальные. И вызываются из глобальных функций. Вообще вся эта песня с get_current была затеяна для чего? В программе есть целая куча тестовых подпрограмм, которые вызываются из командной строки (встроенная консоль) и работают с выделенными обьектами. Примерно так

CONSOLE_CMD(face_test)()
{
  Face *f;
  if ( !get_curr(f) )
     return;
  // отлаживаем методы Face
}

CONSOLE_CMD — это макрос который просто дает функции префикс и добавляет __decslpec(dllexport). Дальше я просто читаю таблицу импорта в экзешнике (эдакий рефлектор кулхакера) и по префиксам вытаскиваю нужные функции, которые делаются доступными во встроенной консоли.
Когда глобальных функций нет и все должно лежать в классах тогда писанины будет больше как ни крути.

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

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

K>>А вот и нет Мы unused юзаем.

IT>Это попытка выпрямить кривой дизайн линзой с обратной кривизной.

А как насчет этого: Например в неком классе Node есть метод соседние-узлы-на-базу-быстро
Node::adjacent_nodes

Пример

vector<Node*> nodes; // временный массив
for (Node *n = face.node_first(); n; n = face.next(n) )
{
   nodes.clear();
   n->adjacent_nodes(nodes);
// далее групируем полученные узлы по какому либо признаку для дальнейшей обработки
   sort(nodes.begin(), nodes.end(), some_criteria);
// дальше поскипано
}

На первой итерации массив nodes заполнится т.е. выделится накая память и если на второй итерации число полученных узлов <= числу узлов на предыдущей то память выделятся не будет, а заюзается то что есть в nodes. Т.е. оптимизация на халяву. А если сделать массив возвращаемым параметром:

vector<Nodes*> Node::adjacent_nodes()

то память будет выделятся по любому. т.е неэффективность на ровном месте на лицо. Иными словами out параметр здесь рулит.

IT wrote:
> Свойства — это удобно. Например, удобно делать отложенную загрузку. Со
> свойствами хорошо работает баиндинг и куча визуальных компонент.
Чем отложенная загрузка не живет с get/set-методами?

> Редактор контролов в студии, например, позволяет редактировать свойства
> контролов прямо в дизайн тайм.
Аналогично в Java — в качестве свойств используется комбинация
get/set-методов.

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

VD>Мне плевать папать чем ты лично занимашся. Но если это:

K>>А под Solaris или HP-UX Mono есть?

VD>то привыкни к мысли, что ты в микроскопическом меньшинстве и мэйнстрим с индустрией слова не про тебя. Ты ремеслинник, возможно виртуозный, занимающийся далекой от народа задачей.

Это похоже на сравнение выпуска легковых автомобилей и аэробусов. На основании того, что каждый год автомобилей выпускается раз в сто тысяч больше, чем самолетов. Получается, что производство автомобилей -- это индустрия и мейнстрим, а самолетостроение -- ремесленичество. Хотя это и правда далекая от народа задача.

K>>VladD2, задачи бывают разные... не только хостинг... и не только под винды... я очень удивлюсь если ты с этим не согласишся

VD>Еще раз. Задачи бывают разные — это столь же бесспорно, как и банально. Так что про это говорить не стоит. Нас же интересуют значительные объемы применения ака мэйнстрим. Так вот значительные объемы применения Линуксов — это исключительно хостинг. По крайней мере пока... но похоже, что и вообще. Радужные прогнозы о захвате Линуксом десктопа оказались мыльным пузырем.

Да и ради бога. Лично мне нафиг Linux или FreeBSD на десктопе не нужен без того количества драйверов, которые есть под Windows. Зато мне нафиг не нужны форточки на сервере, для которого вполне достаточно bash, screen и ssh.

K>>Проект в котором в настояшее время я участвую, живет на Win, Linux, Sun, HP, AIX. При разработке используеться С++, TCL, Java...

VD>Рад за тебя. Можешь спросить у своего начальства сколько у них клиентов под Соляркой или ХаПэ. Мой прогноз — еденицы.

Есть такой класс систем -- банковский процессинг. Их продажи не могут исчисляться тысячами в принципе. Но не смотря на то, что у производителей процессинга клиентов едва переваливает за сотню, между самими производителями процессинга идет весьма серьезная конкуренция. И я очень сильно удивлюсь, если серьезные процессинговые системы для крупных банков (хотя бы уровня ведущих Московских банков, не говоря уже про европейские и американские), работающие под Windows.

Другой пример, ПО для SMS-центров мобильных операторов. Продажи таких платформ исчисляются единицами, а стоимость одной платформы для крупного оператора может достигать не одного миллиона (причем только за софт, без учета соответствующего железа).

Еще один пример. Есть такая платформа HP NonStop (бывший Tandem). Супер надежная, позиционируется как самая надежная платформа в мире и самая выгодная по соотношению цена/производительность для свого класса систем (хотя все это маркетинг и Sun, и Stratuss здесь приводят совершенно другие показатели). При этом машинка минимальной конфигурации стоит под $150K. И на этой платформе работают практически все крупнейшие банки США и Европы, все биржи в США, большинство европейских бирж, большинство сотовых операторов США. А крупнейший NonStop-ный кластер (вроде из 300 юнитов) работает в AOL.

И знаешь, что объединяет все приведенные примеры -- высокие требования к надежности и отказоустойчивости. Это какой-нибудь хостер может выпасть на пару часов в осадок. А вот банк не может остановить свой процессинг. Мобильный оператор не может перестать обслуживать своих абонентов.

Таких клиентов единицы. Но они требуют гораздо больше, чем все рядовые Windows-юзеры вместе взятые (образно говоря). И на создание подобных систем требуется своя индустрия. Естественно, она не мейнстрим. Ты вот, например, о ней даже не задумываешься (если вообще знаешь). А ведь она есть. И приносит совсем не маленькие деньги.

IT wrote:

> _>Куча методов, возвращающих почти одно и то же, но в несколько разных
> видах Face, CFace, QS_Face, QF_Face. Писать кучу геттеров — решение, но
> никак не группирует эти геттеры. И не позволяет манипулировать этой
> кучкой геттеров единообразно.
> А какая тебе манипуляция нужна?
do_something_usefull< Face >(), do_something_usefull< CFace >()...
Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.

> _>? Чем геттер хуже?
> _>Чем геттеры/сеттеры не устраивают?
> Мы же уже выяснили. Тем что приходится писать меньше более читабельного
> кода. В нашем примере это соотношение было 2 раза.
На 2 лексемы "()", если по честному сравнивать "obj.edge vs obj.edge()".

> _>Заметь, в яве обошлись, хоть для тебя это и слабо мыслимо, не слышал,
> чтобы кто-то особо сокрушался по поводу их отсутствия...
> Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться об
> отсутствии того, чего никогда не видел и не пробовал.
Понятно, ты, значит, подсел.
Есть проперти — я их использую, нет пропертей — не использую. Особой разницы в этом не вижу.
Разница примерно как ставить ли ";" в конце строки? В JavaScript не ставлю, в Java — ставлю, и ущербности ни того, ни
другого не ощущаю.

> _>Кстати, там дальше пошли, там понятие bean ввели, более "правильное"
> для компонентной модели. Но зачем это включать в язык?.. это мне не
> совсем кажется большой необходимостью.
> Ты у них спроси сколько надо сделать приседаний и сколько раз постучать
> в бубен, чтобы завернуть обычный джавовский класс в бин. Потом поговорим
> о более "правильном".
А сколько нужно чтобы в COM завернуть? Или в webservice? или corba? Дело в том, что модель такая, требует определённый
формат объектов.
Хотя вот VBA классно в COM заворачивается, но толку-то?.. Там, кстати, и твои любимые проперти есть.

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

IT>Ты у них спроси сколько надо сделать приседаний и сколько раз постучать в бубен, чтобы завернуть обычный джавовский класс в бин.
Ровно 0.

"Бином" (не EJB!) считается любой сериализабельный класс с get/set-методами. Еще бин может опционально поддерживать ноификации о измениниях свойств и рекомендуется иметь конструтор без параметров.

Я уж не говорю, что все уважающие себя IDE давно поддерживают автоматическую генерацию get/set/is-методов.

Kluev wrote:

> Так ведь функции (get_current) глобальные. И вызываются из глобальных
> функций. Вообще вся эта песня с get_current была затеяна для чего? В
Не знаю, странное решение. Когда я решаю использовать глобальную функцию/переменную, я думаю, а может не стоит? Если
всё-таки надумываю что стоит, думаю ещё раз хорошо. И если на этот раз опять решаю, что надо глобальные данные
испольозвать — приходится серьёзно задумываться. И только если после этого решаю, что да, то пишу синлтон.

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

_>do_something_usefull< Face >(), do_something_usefull< CFace >()...
_>Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.

Вобще-то решается. Нужно только, чтобы Face и CFace реализовывали общий базовый интерфейс IFace, а функция do_something_usefull получала фабрику IFace в качестве аргумента. Только совсем не факт, что Face и CFace можно будет от IFace унаследовать. И такой вариант, на основе виртуальных методов и фабрик (т.е. с динамическим выделением памяти), очень вероятно, будет медленнее шаблоного.

Более того, можно и обратный пример, когда есть get_current_face, get_current_edge, get_current_surface (вместо одного перегруженного get_current) с шаблоном do_something_useful подружить. Через специализацию шаблонов:

// Без специализации порождаем ошибку.
template< class T > struct getter {};

// Конкретные специализации.
template<> struct getter< Face > { Face * operator()() { get_current_face(); } };
template<> struct getter< Edge > { Edge * operator()() { get_current_edge(); } };
template<> struct getter< Surface > { Surface * operator()() { get_current_surface(); } };

template< class T >
void do_something_useful() {
  T * t = getter< T >()();
  ...
}

Писанины, однако, явно больше.

Поэтому вариант do_something_useful<> на шаблонах и get_current() с out-параметром, имхо, выглядит самым прагматичным. Более того, если классы Face, Edge, Surface имеют какие-то не очень серьезные различия в интерфейсах (скажем, разные названия некоторых методов) из-за отсутствия общего корня иерархии наследования, то эти различия можно легко скрыть за шаблонами вроде показанного выше getter.

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

IT>>Это конечно круто защищать комитет и не знать, что двойное подчёркивание зарезервировано для разработчиков компиляторов.

E>Тем не менее, это не имеет никакого отношения к осмысленности выбираемый мной идентификаторов. Так что говори лучше по существу.



E>Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.

По существу. get_current_edge — диалог? Ты бы ещё назвал эту функцию оператором ++.

E>Это серьезный аргумент против out-параметров, но ты его не озвучил.

Просто я такими "серьёзными" аргументами уже давно не страдаю, начал подзабывать

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

E>>Но в данном примере речь не шла о кодах возврата. Речь шла о функии, которая возвращала bool в качестве признака успешности или неудачности завершения. Примером такой функции может быть запрос параметров в диалоге у пользователя, когда bool означает, что пользователь ввел все, что нужно и нажал Ok. Более подробной диагностики здесь не нужно.

IT>По существу. get_current_edge — диалог? Ты бы ещё назвал эту функцию оператором ++.

Я же сказал

примером такой функции

.
Например, get_current_edge может возвращать true, если edge с момента последнего обращения к get_current_edge изменился (как раз в результете взаимодействия с пользователем) или false, если edge не изменялся.

E>>Это серьезный аргумент против out-параметров, но ты его не озвучил.

IT>Просто я такими "серьёзными" аргументами уже давно не страдаю, начал подзабывать

Еще скажи, что в managed языках вообще нет необходимости обеспечивать гарантию безопасности исключений.

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

_>Это, конечно, обычным наследованием решается, ладно, забудь, ибо шаблонов ты пугаешься.



_>На 2 лексемы "()", если по честному сравнивать "obj.edge vs obj.edge()".

Не надо нам тут фальсификаций. Было obj.get<edge>().

>> Ты же ведь тоже не сокрушается, правда? Потому что трудно сокрушаться об отсутствии того, чего никогда не видел и не пробовал.
_>Понятно, ты, значит, подсел.

Можно и так сказать. Подсел на удобный и красивый язык без мусора в виде бесконечных преобразований строк, без '->', '::' и прочих птичьих наворотов.

_>Есть проперти — я их использую, нет пропертей — не использую. Особой разницы в этом не вижу.
_>Разница примерно как ставить ли ";" в конце строки? В JavaScript не ставлю, в Java — ставлю, и ущербности ни того, ни другого не ощущаю.

Ради бога, на здоровье. Я же не против. Жалко, конечно, что такие хорошие ребята, вот так запросто так калечат себе судьбы, но... что делать


_>А сколько нужно чтобы в COM завернуть? Или в webservice? или corba? Дело в том, что модель такая, требует определённый формат объектов.

В ком и корба — это да. Вебсервисы или ремоутинг делается в .NET без приседаний. Вебметод делается навещиванием на метод соответствующего атрибута. Через ремоутинг объект делается доступным путём наследования от соответствующего объекта. Но почему это возможно и что такое метадата в .NET тема для отдельного разговора.