Здравствуйте, VladD2, Вы писали:
VD>А можно shrink == уплотнение?
Ну, с такими вопросами — сюда.

VladD2 пишет:
> Встраивая поддрежку паттерна в язык разработчики этого языка обычно
> довольно глубоко продумывают что и как делать. В противном случае они
> просто угробят язык. А необходимость обратной совместимости не даст
> исправить ошибку в дальнейшем. Все это праткически гарантирует высокое
> качество реализации. Ну, а то что появляется стандарт на реализацию и

Каким образом огромная ответсвенность гарантирует качество реализации?
Имхо, угробление уже началось. C#1 был явно проще. Пусть даже с меньшими
наворотами.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

VladD2 пишет:
> C>чем только можно. Лучше бы создателям С# это понять, а не пытаться
> C>адаптировать систему типов под SQL, XML и т.п.
>
> Не боись. Они явно не тупее нас с тобой.

Кстати, вот в треде об обучении я видел высказывание, что зачем учить
другие языки, один выучил, что самый на рынке популярный и вперёд. В
связи с этим возник вопрос, а кто тогда разрабатывает новые платформы,
языки, системы? Откуда они берутся?
Это действительно совсем ни у кого из ныне учищахся нет куража от того,
что разобрался сам как работает система, и сделал по-другому?
Может лучше, может хуже, но сделал сам. Или просто такие люди
сюда не пишут, а тихонько себе что-то хачут?
Настолько ли сильно ли подготовка буржуинов лучше чем у нас, что можно
ожидать, что они сделают сразу всё правильно и на благо простых
программеров?

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

Здравствуйте, Cyberax, Вы писали:
>> C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если
>> C>подумать, то можно накопать и еще таких камешков подводных.
>> Ну, то-есть если компилятор все проверить не может, то ничего
>> проверять не нужно? Логика еще та.
C>Если компилятор не может проверить _адекватно_, то лучше уж пусть не
C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих
C>заморочек — и если сделать что-то общее для всех СУБД, то получится
C>весьма ограниченная функциональность.
C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на
C>С++ные шаблоны и переопределенные операторы.
А после того, как ты структуру БД поменяешь или изменишь тип поля в таблице, шаблоны компилиться перестанут. Ага.

>> C>Есть ли в Линуксе OLE и DCOM?
Кто и где обещал ДКОМ не под винды?

>> За бабки есть. Хотя наверно, кое что есть и бесплатно.
C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за
C>почти любую цену).
Значит что-то всё-таки есть, а выделенное уже субъективное мнение, да?

>> C>Так вся OLE вокруг IDispatch'а построена.
>> Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том,
>> в чем не понимашь?
C>Пальцем в небо — OLE я знаю досконально. Сейчас вот как раз дописываю
C>ActiveX-контейнер из ATL
C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. В
C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут
C>малополезны, так как их свойства нельзя будет редактировать из VB/Delphi/...
Ты мешаешь в кучу ОЛЕ, КОМ, АХ, ДКОМ... Что бы всё запутать, да?
Приведи ссылку или расскажи какую именно МС обещала кроссплатформенность и в чём. Мне кажется это немного отличается от того, что тебе хочется получить, и обижаться на МС за это неспортивно

Здравствуйте, Cyberax, Вы писали:
>>>> И что это даст? Они и в виде классов вписываются в концепции языка
>>>> очень хорошо.
>> C>Ну так и SQL тоже.
>> В SQL синтаксис есть, например, который компилятор проверить может.
C>А в 3D компилятор мне не сможет проверить, что у меня матрица не
C>сингулярная.
Гы. Приходится описывать килограммы константных матриц?? Я дел с графикой не имел, так что поправь пожалуйста, если я ошибаюсь.
Приведи примерчик кода, в котором компилятор "3D компилятор мне ... сможет проверить, что у меня матрица не сингулярная".

>> Так же есть описание того, как база данных устроена, по каким правилам
>> "живёт". Значит и семантику проверить можно. А в графике чем он жизнь
>> упростит?
C>В графике есть, например, языки шейдеров.
не оно? http://microsoft.cs.msu.su/projects/ilshaders/

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

>> C>Далее, статическая проверка SQL
>> C>потребует наличие схемы базы данных и DB-specific-драйвера при
>> C>компиляции исходника — а это выглядит слегка странно.
>> Что именно в этом "странно"?
C>Что для компиляции требуется DB-specific модули.
"Что именно в этом "странно"?" Я так и не вижу ничего "этакого"...

>> C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping
>> решения
>> C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще
>> C>чего-то добавлять в язык?
>> Избавить от бесконечных проверок типов разработчиков ОРМ и повысить
>> тем самым надёжность их продукции.

C>А проверки типов из такого никуда не уйдут — они просто спрячутся. А для
C>ORM обычно есть инструменты, которые позволяют провалидировать maping
C>относительно данной БД.
Проверки типов будут происходить в компаил-тайм, а не в рантайме (я надеюсь ). Разница есть?

_FRED_ пишет:

> C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на
> C>С++ные шаблоны и переопределенные операторы.
> А после того, как ты структуру БД поменяешь или изменишь тип поля в
> таблице, шаблоны компилиться перестанут. Ага.

Если вынести мэпинг в отдельный XML-файл, то вполне можно сделать его
валидацию на этапе компиляции. Более того, это УЖЕ сделано в Hibernate.

>>> C>Есть ли в Линуксе OLE и DCOM?
> Кто и где обещал ДКОМ не под винды?

ms-help://MS.MSDNQTR.2005JAN.1033/dndcom/html/msdn_dcombiz.htm

Microsoft is openly licensing DCOM technology to other software
companies to run on all of the major operating systems, including
multiple implementations of UNIX-based systems. Software AG has DCOM
running on the Solaris-based operating system today. Additionally,
Microsoft is handing over DCOM technology with other core ActiveX
technologies to The Open Group. The Internet Draft technical publication
that contains a publicly available description of the DCOM network
protocol can be found at
http://www.dc.luth.se/doc/id/draft-brown-dcom-v1-spec-00.txt.

>>> За бабки есть. Хотя наверно, кое что есть и бесплатно.
> C>Даже за бабки нет ничего *нормального* (мы искали, причем взяли бы за
> C>почти любую цену).
> Значит что-то всё-таки есть, а выделенное уже субъективное мнение, да?

Ситуация такая: было сложное приложение, сделанное на COM. Заказчик
когда-то повелся на обещания МСа сделать все открытым и
многоплатформенным. Мы тестировали несколько портированных COMов, но ни
один из них не подошел для портирования — везде чего-то не хватало.

> C>Пальцем в небо — OLE я знаю досконально. Сейчас вот как раз дописываю
> C>ActiveX-контейнер из ATL
> C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. В
> C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут
> C>малополезны, так как их свойства нельзя будет редактировать из
> VB/Delphi/...
> Ты мешаешь в кучу ОЛЕ, КОМ, АХ, ДКОМ... Что бы всё запутать, да?

А чего их отделять? Те же AXы — это обрезанный OLE с небольшими
добавлениями. DCOM — это COM с межмашинным маршалингом.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

VD>>А можно shrink == уплотнение?
S>Ну, с такими вопросами — сюда.

Вообще-то это был не впрос.

Для полного счастья — другой пример:
select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2

С уважением, Gleb.

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

GZ>Для полного счастья — другой пример:
GZ>select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2

for $x in /a return $x[ @f=/b[ @f1=/c[ @f2=$x/@f2 ]/@f1 ]/f ]

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

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

GZ>>Для полного счастья — другой пример:
GZ>>select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2

V>for $x in /a return $x[ @f=/b[ @f1=/c[ @f2=$x/@f2 ]/@f1 ]/f ]

О, а лучше так:

FOR $a IN /a, $b IN /b, $c IN /c RETURN $a[ ($a/@f=$b/@f) AND ($b/f1=$c/@f1) AND ($c/@f2=$a/@f2)  ]

Получилось один в один.

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

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

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

GZ>>>Для полного счастья — другой пример:
GZ>>>select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2

V>>for $x in /a return $x[ @f=/b[ @f1=/c[ @f2=$x/@f2 ]/@f1 ]/f ]

V>О, а лучше так:
V>

V>FOR $a IN /a, $b IN /b, $c IN /c RETURN $a[ ($a/@f=$b/@f) AND ($b/f1=$c/@f1) AND ($c/@f2=$a/@f2)  ]
V>

V>Получилось один в один.
Уже лучше. Предыдущий я чего-то не понял. Это правда не является XPath а скорее XQuery, и возвращает объекты, а не набор полей, но за решение респект. Дюже понравилось.

С уважением, Gleb.

PS: Неужели вся эта фигня будет работать?

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

GZ>Это правда не является XPath а скорее XQuery,
XPath 2.0
http://www.w3.org/TR/2005/WD-xpath20-20050211/#id-for-expressions

GZ>PS: Неужели вся эта фигня будет работать?
ХЗ

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

C>А чего такого? Все очень просто:
Да уж. Проще не бывает.

>> C>На C# проще не будет — тут получается именно функциональный язык с
>> C>ленивым выполнением.
>> Чже же тут ленивого?

C>Вычисления производятся только тогда, когда они нужны, а не когда
C>впервые встретились.

Что-то я не заметл там "когда они нужны". Там массив по которому и делаются вычисления. Что я пропустил?

C>

C>boost::function func<>(_arg1++ + _arg2);
C>func(4,5);
C>

C>Чуть пооптимизировал

А ты не оптимизируй. А то фигня выходит. Если ты еще не въехал, то поясняю a(4) — это функция (сслка на нее) которая позволяет частично задать значение другой функции. "4" запоминается в возвращаемом результате "а" и при вызое используется для вычислений. И заметь, никаких библиотек не требуется. Функциональное программирование по полной программе, без эмуляций и ограничений.

Что же касается ленивых вычислений, то попробуй повторить на С++ вот такую примитивную конструкцию:

static IEnumerable<int> XRange(int start, int len, int inc)
{
    int count = (len - start) / inc;
    for (int val = start, i = 0; i < count; i++, val += inc)
        yield return val;
}

и сравни с оригиналом.

C>std::vector — и ваши волосы будут мягкими и шелковистыми.

Ну, значит ты согласен, что встроенные массивы С++ ни на что не годны и даже если нужен массив с фиксированной длинной прийдется применять класс-хэлпер?

Вот так по капле и получается трах на ровном месте. Я тут как-то делал программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2 минуты. На С++ протрахался час.

C>0. Мне нравится как спроектирован Swing..
C>1. В WF нет разделения на модель и вид.

Ну, это не совсем так. Тот же DataGrid вроде как по ней работает. ListBox тоже. Свинг конечно идеологически не плох, но реализация у него явно хромает.

C>2. Нет layout'ов.

Во втором фрэймворке реализованы в виде отдельных котролов.

C>3. СЛИШКОМ сильное использование наследования.

Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные недостатки.
В общем, только всего уложилось в то, что в Свинге больше ориентировано на внешнюю модель.

Да и какое отношение имет язык к фрэйворку? Ими занимаются разные люди. Даже разными частями фрэймворка занимаются разные люди.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>VladD2 пишет:
>> C>чем только можно. Лучше бы создателям С# это понять, а не пытаться
>> C>адаптировать систему типов под SQL, XML и т.п.
>>
>> Не боись. Они явно не тупее нас с тобой.

ANS>Кстати, вот в треде об обучении я видел высказывание, что зачем учить
ANS>другие языки, один выучил, что самый на рынке популярный и вперёд.

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

ANS> В
ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы,
ANS>языки, системы?
ANS> Откуда они берутся?

Задай это тому от кого ты это слышал.

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

Однако много вопросов можно задать если приписать собеседнику слова которых он не говорил...

ANS>Настолько ли сильно ли подготовка буржуинов лучше чем у нас, что можно
ANS>ожидать, что они сделают сразу всё правильно и на благо простых
ANS>программеров?

... Очень много...

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>VladD2 пишет:
>> Встраивая поддрежку паттерна в язык разработчики этого языка обычно
>> довольно глубоко продумывают что и как делать. В противном случае они
>> просто угробят язык. А необходимость обратной совместимости не даст
>> исправить ошибку в дальнейшем. Все это праткически гарантирует высокое
>> качество реализации. Ну, а то что появляется стандарт на реализацию и

ANS>Каким образом огромная ответсвенность гарантирует качество реализации?

Это даже как-то не ловко объяснять. Это все равно что обяснять что холодный, или что такое синий цвет.

ANS>Имхо, угробление уже началось. C#1 был явно проще. Пусть даже с меньшими
ANS>наворотами.

А, по-моему, ты делаешь предположения не попробовав. Программировать стало только проще. Новые фичи просто снимают некоторые заботы с программиста и увеличивает контроль со стороны компилятора.

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

C>Если компилятор не может проверить _адекватно_,

Кто сказал? Он как раз может адекватно проверить.

C> то лучше уж пусть не
C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих
C>заморочек — и если сделать что-то общее для всех СУБД, то получится
C>весьма ограниченная функциональность.

Зачем низная ничего о реализации делать предположения? Пусть делают. Сделают — скажем спасибо. Не сделают, значит и вправду слишком сложно и не универсально получилось.

C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на
C>С++ные шаблоны и переопределенные операторы.

Ага. Языком. А на практике для доступа к БД С++ используют только маньяки. Да и не дают шаблоны ровным счетом ничего. Основная проблема заключается в том, что нет контроля на переходе между мирами. И в том, что ошибки не могут быть проверены до запуска программы.

>> C>Есть ли в Линуксе OLE и DCOM?
>> За бабки есть. Хотя наверно, кое что есть и бесплатно.

C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за
C>почти любую цену).

Вы плохо искали. Есть несколько реализаций. В том числе тут рядом обсуждался один из вариантов. Там не только КОМ, но и АТЛ с МФЦ дают. А классика есть у CA.

>> C>Так вся OLE вокруг IDispatch'а построена.
>> Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том,
>> в чем не понимашь?

C>Пальцем в небо — OLE я знаю досконально.

Я плякаль. Досканальное знание ОЛЕ и при этом не знает, что IDispatch появился в VB значительно позже ОЛЕ. ОЛЕ 1 даже на КОМ не было основано. КОМ собственно и родился как побочный продукт разработки ОЛЕ.

C> Сейчас вот как раз дописываю
C>ActiveX-контейнер из ATL

Рад за тебя. Я такой фигней бросил заниматся еще в 2001. Можешь взять готовый.

C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов.

Знаток, блин. ActiveX-ы появились лет эдак через 10 после появления ОЛЕ 1 и через где-то 5 после ОЛЕ2. Они базировались на ОЛЕ. По началу они так и назывались OLE Control eXtention, или OCX. IDispatch же появился в VB (если не ошибаюсь 3 или 4) когда в нем технология VBX была заменана на OCX. На сегодня дисптч относят к Automation API. В начале его назвали OLE Automation API, но потом переименовали, так как мода называть все "ОЛЕ" закончилась и началась мода "+" и "Active".

C> В
C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут
C>малополезны, так как их свойства нельзя будет редактировать из VB/Delphi/...

Очень смешно слышать пдобное от досканального знатака ОЛЕ. Оле и расшифровывалось как Обжект Линкинг этд Эмбединг. Изначально это интерфейс для связывания Ворда с Экселем (чтобы в Ворд можно было вставлять табличку из Экселя). Ну, и нет никаких проблем создать ActiveХ который будет использовать исключительно кастом-интерфейсы и прекрасно работать в ВБ (и уж темблее в Дельфи).

Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс даст им 100-кртаную фору.

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

>>> C>Есть ли в Линуксе OLE и DCOM?
_FR>Кто и где обещал ДКОМ не под винды?

Расслабьтесь http://www.google.ru/search?hl=ru&q=DCOM+on+Unix&lr=

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

C>Новая шутка: стандартный синтаксис SQL. Запомню.

Да, уж. Потрудись: http://aam.ugpl.de/book/print/157 .

C>А _ЗАЧЕМ_ добавлять ради этого новые сущности в язык?

Я еще не говорил? Чтобы обеспечить статический контроль типов.

C>А омегу сразу все захотят.

C# Х.

>> C>Кроссплатформенности нормальной нет, только.
>> Просто потому-что тебе так хочется? А ничего, что несколько
>> поставшиков все же предлагает КОМ на других платформах?

C>Мы тестировали несколько продуктов. В основном там перенесены простейшие
C>функции типа создания объектов, маршалирование по библиотекам типов и
C>т.п. Но ни один из них не поддерживает полностью модель
C>ActiveX-контролов и полную спецефикацию RPC.

Про RPC — это не правда. ActiveX — это вообще набор интерфейсов. Контейнеров куча. Хотя бы наш живет на голом КОМ-е.

>> C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология
>> C>IDispatch вообще не вписывается, например.
>> Дык где в язык КОМ не встроен, так монечно было не здорово. Но где был
>> встроен, там опять таки все ОК. Погляди на VC и C++Builder. В них
>> можно довольно просто использовать любые КОМ-объекты обладающие
>> библиотекой типов

C>Получается уродство в красивой обертке.

Дык КОМ иделом и не был. В области компонентного прграммирования дотнет и Ява рулят одназнача.

VladD2 пишет:

> C>Вычисления производятся только тогда, когда они нужны, а не когда
> C>впервые встретились.
> Что-то я не заметл там "когда они нужны". Там массив по которому и
> делаются вычисления. Что я пропустил?

Возьмем этот же пример: "_arg1++ + _arg2". Операция _arg1++ генерирует
функтор, принимающий на вход первый аргумент и увеличивающий его на 1.
_arg2 — это функтор, который ничего не делает. Далее идет операция "+",
которая создает третий функтор, принимающий на вход два других функтора.
Это сложно рассказывать — надо показывать.

>
>C>boost::function func<>(_arg1++ + _arg2);
>C>func(4,5);
>C>
>
>
> C>Чуть пооптимизировал
> А ты не оптимизируй. А то фигня выходит. Если ты еще не въехал, то
> поясняю a(4) — это функция (сслка на нее) которая позволяет частично
> задать значение другой функции. "4" запоминается в возвращаемом
> результате "а" и при вызое используется для вычислений.

Так тут абсолютно тоже самое. _arg++ — функция, _arg2 — функция, а +
комбинирует две функции.

> Что же касается ленивых вычислений, то попробуй повторить на С++ вот
> такую примитивную конструкцию:
>
>static IEnumerable<int> XRange(int start, int len, int inc)
>{
> int count = (len — start) / inc;
> for (int val = start, i = 0; i < count; i++, val += inc)
> yield return val;
>}
>
> и сравни с оригиналом.

http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

int XRange(ccrContParam,int start,int len,int inc)
{
    ccrBeginContext;
    int i,count,val;
    ccrEndContext(foo);

    ccrBegin(foo);
    count=(len-start)/inc;
    for (foo->i=0,foo->val=start; foo->i<count; foo->i++,foo->val+=inc)
    {
        ccrReturn(foo->val);
    }
    ccrFinish(-1);
}

Что характерно, если развернуть макросы и сравнить со сгенерированным
кодом для C#, то получится примерно одно и то же.

> C>std::vector — и ваши волосы будут мягкими и шелковистыми.
> Ну, значит ты согласен, что встроенные массивы С++ ни на что не годны
> и даже если нужен массив с фиксированной длинной прийдется применять
> класс-хэлпер?

Массивы на С++ настолько гибкие, что без ограничителей с ними сложно
работать
А для массива с фиксированной длиной есть еще и boost::array.

> Вот так по капле и получается трах на ровном месте. Я тут как-то делал
> программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2
> минуты. На С++ протрахался час.

Это не показатель. Может быть я тоже самое написал бы за 5 минут.

> C>0. Мне нравится как спроектирован Swing..
> C>1. В WF нет разделения на модель и вид.
> Ну, это не совсем так. Тот же DataGrid вроде как по ней работает.
> ListBox тоже. Свинг конечно идеологически не плох, но реализация у
> него явно хромает.

Согласен, реализация Свинга хромает (хотя последние версии очень даже
нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь
наконец-то создаст нормальный GUI-фрэймворк.

> C>2. Нет layout'ов.
> Во втором фрэймворке реализованы в виде отдельных котролов.

Посмотрю.

> C>3. СЛИШКОМ сильное использование наследования.
> Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные
> недостатки.

Hint: кроме наследования есть еще и делегирование и аггрегирование.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:

> C>Новая шутка: стандартный синтаксис SQL. Запомню.
> Да, уж. Потрудись: http://aam.ugpl.de/book/print/157 .

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

> C>А _ЗАЧЕМ_ добавлять ради этого новые сущности в язык?
> Я еще не говорил? Чтобы обеспечить статический контроль типов.

Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО ОТДЕЛЬНОГО
СЛУЧАЯ — то это лучше не делать вообще.

> C>Мы тестировали несколько продуктов. В основном там перенесены
> простейшие
> C>функции типа создания объектов, маршалирование по библиотекам типов и
> C>т.п. Но ни один из них не поддерживает полностью модель
> C>ActiveX-контролов и полную спецефикацию RPC.
> Про RPC — это не правда.

Правда, полностью его нормально никто не сделал.

> ActiveX — это вообще набор интерфейсов. Контейнеров куча. Хотя бы наш
> живет на голом КОМ-е.

Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию контейнера.

> C>Получается уродство в красивой обертке.
> Дык КОМ иделом и не был. В области компонентного прграммирования
> дотнет и Ява рулят одназнача.

Согласен.

--
С уважением,
Alex Besogonov (alexy@izh.com)