Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет mumuntu ([info]mumuntu)
@ 2004-01-30 18:07:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
[News] Я дожил, ура!
Microsoft отказывается от компонентной объектной модели.
НАКОНЕЦ-ТО!!!

(Добавить комментарий)


[info]blacklion@lj
2004-01-30 12:12 (ссылка)
Бред.

(Ответить) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 12:15 (ссылка)
Думаешь, не откажутся?
Откажутся, я уверен.
Или wrapper'ы сделают для COM-объектов SOAPовские.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]blacklion@lj
2004-01-30 12:18 (ссылка)
Откажутся. Тут сомнений нет.
Аргументация бредовая.
CORBA ужасна, да (по реализации, не по идее -- ее сугбил комитет, одни маппинги в C++ Чего стоят). Но вот COM, да с поддержкой в компиляторе (когда просто #import'ишь TLB'шку и все калссы у тебя в руках) -- наредкость удачная технология.
DCOM, конечно, похуже. Но и SOAP тут не подарок.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 13:07 (ссылка)
Хе-хе.
Ну рассказывай тогда, в каком языке COM удачная технология.
Я тоже хочу использовать этот язык.
А то мне доводилось только писать сервера на C++ и это было реальное г.
Использовать сервера из клиентов на C++ - тоже г. то еще.
Вполне допускаю, что это из-за моей собственной необразованности.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]piggymouse@lj
2004-01-30 13:26 (ссылка)
Visual Basic. Ахуенно удобно. Seriously.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 13:48 (ссылка)
Если бы на нем можно было делать что-нибудь еще, кроме склейки нескольких COM-объектов...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]piggymouse@lj
2004-01-30 13:55 (ссылка)

Ну, скажем так – он настолько хорошо склеивает COM-объекты, что остальные вещи можно сделать и на чём-нибудь ещё.

Кстати, я тут всё собираюсь по свежим следам написать заметку о том, как сильно сосёт Дельфи.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 14:02 (ссылка)
Не забудь написать о том, почему он сосет.
А то я чувствую, что сосет, а объяснить не могу. :)

(Ответить) (Уровень выше)

Re:
[info]alexshubert@lj
2004-01-30 14:11 (ссылка)
Убью.
:)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 14:30 (ссылка)
Спакуха на фейсе, мы тебя научим нормальным языкам! :)

(Ответить) (Уровень выше)


[info]piggymouse@lj
2004-01-30 17:10 (ссылка)

Руки коротки.

Нет, конечно же для любительских поделок in house и для какого-нибудь простихосподи прототипирования ХУИ Дельфи вполне сгодится. Я имею в виду продукты для реально больших рынков или проекты для реально больших заказчиков.

(Ответить) (Уровень выше)


[info]piggymouse@lj
2004-01-30 13:29 (ссылка)
А на Ц++ КОМ, конечно, реально ужасен. Всё ж таки, C++ is a COM assembler.

(Ответить) (Уровень выше)

Re:
[info]blacklion@lj
2004-01-30 13:54 (ссылка)
C++ + MS'овский компилятор + ATL -- и никаких проблем у меня не бывало.
Для сервера, конечно, возни побольше, но для клиента -- все вообще в три действия. Импортим TLB'шку (расширение C++ от MS), заводим умный указатель (тип будет создан компилятором), инициализируем его именем компонента. ВСЕ. Дальше у нас в руках обычный C++ класс (интерфейс). При необходимости -- приводим его к другому типу (берем дургой интерфейс) и так далее.
Придумать куомпонентную технологию удобнее я просто не могу.

Конечно, дело тут на только и столько в COM'е, сколько в поддержке всего этого компилятором. Никто не мешал сделать тоже самое в другом компиляторе для CORBA (хотя бы и в GCC), но ведь никто не сделал...

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]alexclear@lj
2004-01-30 14:09 (ссылка)
C++ + MS'овский компилятор + ATL -- и никаких проблем у меня не бывало.

У меня проблемы, что с MSVC и ATL.
Меня от них в связке просто тошнит.
MSVC+MFC(любят остальные участники проекта MFC containers не пойму за что)+ATL - такая помойка, что врагу не пожелаю копаться. А если еще сюда MSSOAP и MSXML добавить, то это вообще %^$#$%.

Импортим TLB'шку (расширение C++ от MS), заводим умный указатель (тип будет создан компилятором), инициализируем его именем компонента.

Вот! А как это понять программисту, который в основном работал в рамках стандарта ANSI C++ и MSVC использовал весьма эпизодически?

ВСЕ. Дальше у нас в руках обычный C++ класс (интерфейс). При необходимости -- приводим его к другому типу (берем дургой интерфейс) и так далее.

Еще я пытался MSDN читать по поводу COM. Всего три слова - НУ И ДЕРЬМО! Технология настолько стара, что в хелпе переплетаются всевозможные статьи, написанные на разных уровнях развития COM. Что к чему, понять совершенно невозможно.

Придумать куомпонентную технологию удобнее я просто не могу.

Да придумать-то ладно, можно ведь было еще и реализовать ее по-людски!

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re:
[info]blacklion@lj
2004-01-30 16:00 (ссылка)
MFC сам не люблю. MSVC -- приличный компилятор, на среду -- наплевать, есть знакомые, которые работают в Emacs'е с ним. Все работает :)

Что значит "как понять"? Прочитать доку, блин. #import посмотри в MSDN, книжку по ATL купи. И по COM'у заодно (именно по COM, а не по OLE).

Стара и многослойна -- это да. Поэтому надо начианть с хорошей книжки, причем именно по COM а не OLE/ActiveX и прчоим НАДСТРОЙКАМ.

IMHO, как раз, и реализовнао максимально по-людски. тот же CORBA в разы неудобнее с ее CORBAString'ом и прочим уродством.

Кстати, если не секрет, где ты взял компиялтор ANSI C++? У вас Comeau куплен? :)

(Ответить) (Уровень выше)

Re:
[info]alexclear@lj
2004-01-30 12:16 (ссылка)
А про CORBA и RMI - и правда бред.

(Ответить) (Уровень выше)


[info]piggymouse@lj
2004-01-30 12:18 (ссылка)

Как меня всё заебало!!!

Особенно местные журналисты.

Главным моментом в выступлении Бокса стала мысль о том, что объектно-ориентированные технологии обмена данными между программами, разрабатывающиеся компанией с начала 90-ых годах.

Что блядь касается неоконченных предложениям.

(Ответить) (Ветвь дискуссии)


[info]piggymouse@lj
2004-01-30 12:22 (ссылка)

Box stressed that COM and DCOM are not dead. (http://news.com.com/2100-1046_3-5148148.html)

Ну и хули такие заголовки писать? Вольные сказители, йопть.

(Ответить) (Уровень выше)

Re:
[info]alexclear@lj
2004-01-30 13:15 (ссылка)
Вот оно, Настоящее!

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]piggymouse@lj
2004-01-30 13:25 (ссылка)
Настоящий пиздец.

(Ответить) (Уровень выше)

Вперед, к PDF-RPC!
[info]potan@lj
2004-01-30 12:42 (ссылка)
Я думаю что это первый шаг к действительно human friendly протоколу. В ближайщих планах передача данных формата PDF. Разметка данных будет производиться не труднопонимаемыми xml-тегами, а соответствующим фонтом.

(Ответить) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]alexclear@lj
2004-01-30 13:14 (ссылка)
Да дело ведь не в том, в каком формате данные гонять. А в том, сколько ударов по бубну надо сделать, чтобы клиент смог доступиться к серверу.
В этом смысле COM, по моему, хуже чем plain TCP.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]potan@lj
2004-01-30 13:40 (ссылка)
Мне, почему-то, не кажется, что подключить vim к visualc станет проще, если visualc начное общаться с VisVim.dll на xml, а не через com.
Но то, что это будет происходить значительно медленнее, это просто гарантированно.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]piggymouse@lj
2004-01-30 13:57 (ссылка)
Да что там SOAP?! Жизнь – говно! ©[info]caseq@lj

(Ответить) (Уровень выше)

Re: Вперед, к PDF-RPC!
[info]alexclear@lj
2004-01-30 14:01 (ссылка)
Мне, почему-то, не кажется, что подключить vim к visualc станет проще, если visualc начное общаться с VisVim.dll на xml, а не через com.

А разве тогда был выбор?

Но то, что это будет происходить значительно медленнее, это просто гарантированно.

Производительность просядет, конечно, но о значительном замедлении я бы не стал говорить. Что такое мы сделали с протоколом, отчего он вдруг стал сильно хуже? Добавили время на разбор XML? А разве маршалинг в COM времени не занимает?

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]potan@lj
2004-01-30 14:12 (ссылка)
Бинарный маршалинг и парсинг текстовых документов? Скорость на порядок упадет.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]alexclear@lj
2004-01-30 14:29 (ссылка)
Сложно сказать.
Зависит от того, насколько большой процент общего времени занимает собственно пересылка данных. Бинарный маршалинг быстрее, я не спорю, за счет отсутствия необходимости в разборе. Но, если хорошо оптимизировать парсер и способ передачи XML, можно свести время на разбор к минимуму.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Вперед, к PDF-RPC!
[info]piggymouse@lj
2004-01-30 17:14 (ссылка)

Martin Fowler's Golden Rule for Distributed Objects:

DON'T DISTRIBUTE YOUR OBJECTS!

(Ответить) (Уровень выше)


[info]mivlad@lj
2004-01-30 17:59 (ссылка)
XML — зло, как правило.

(Ответить)