ZEN>Я считаю: меньше размер -- меньше потенциальных ошибок в коде.
ZEN>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?

Это вам кто-то из посвящённых на совместной пьянке рассказал? У меня лично SP1 beta1 для XP 117 Мб занимает...

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

IT>Но, но, но! Я папрашу!
IT>Я заменял, заменяю и буду заменять все комы, которые только можно, на web-сервисы. У меня проблем с их скоростями нету, надо будет ещё пару процессоров в сервер воткнём. А вот deployment меня волнует серьёзно. После каждого изменения COM-объекта перегружать сотни рабочих станций мне никто не позволит. С remoting на клиентах тоже пока сильно не разбежишься, так что получается, что пока WS — спасение от всех зол.

А вот можно поподробнее — пачему ремотинг хуже веб-сервисов? У вас клиенты не дотнетовские?

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

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

VD>>>Если они посчитали что изменений много, то нужно было довать версию 2 (или 7 как MS), а не заниматься дурью.
AVK>>Да какая нафик разница. Как не называй, суть то одна.

VD>Неразбериха. Вот суть таких именований.

Ага. MS можно, а Sun нельзя? MS Word6 помним, MS Word7 помним(?), MS Word97 помним (где "настоящая" версия 8?), и так далее...

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

VD>В восьмедисятых для таких преобразований приспособили слово перестройка. :)

AVK>>Это революция не вобще, а по сравнению с предыдущей версией.

VD>Дык если есть версии, то однозначно эволюция. Типа лапки вместо плавников.

AVK>>Какой такой? 1.1.6 был вполне применим в коммерческих проектах. Скорость его была конечно же поменьше 1.3, но для многих задач вполне достаточна.

"Проба пера" JIT-а.

VD>Я о том, что на разницу в двое я глаза еще закрою, но в 10 раз — это уже перебор, а 1.1.х тормозили по черному. Есть задачи не критичные ко времени, но вом мне все как-то другие попадаются. :(

Тормозило без JIT-а и с самыми первыми JIT-ами.

AVK>>Рефлекшн джавы не обеспечивает достаточную для реализации визуального программирования функциональность. Там нет способа сказать что тот или иной метод на самом деле property accessor

Так ли не обеспечивает? И всё ли нужно?
Reflection может выдать только ту информацию о классе, его методах и полях, которая содержится в уже откомпилированном классе. По-моему, избыточной информации для RUN-TIME быть не должно, а для DESIGN-TIME должен предоставляться BeanInfo и, по желанию, "навороченные" PropertyEditors и только в том случае, если разработчик Bean-а захочет, чтобы Вы использовали его компонент в СРЕДЕ РАЗРАБОТКИ и/или Bean-контейнере.
Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи.

VD>Ну, это они вроде неплохо и по именам отиличают. В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют).

AVK>>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.

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

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

Нет, он решает определённые задачи.
Java-рефлекшн может дать то, что есть, не больше, не меньше. А обычно есть только самое необходимое для работы в Run-time. Для Design-time требуются (подчёркиваю: необязательно!!!) дополнительные классы поддержки разработки: BeanInfo -- для корректного отображения свойств компонента в ObjectInspector-ах различных IDE (например, отобразить цвет не словами, а цветной фигуркой, тип цветной фигурки может быть на совести IDE или PropertyEditor-а) и PropertyEditor-ы -- для "наикрутейшего" доступа к "свойствам" (например, задание коннекта к БД одной строчкой, но после вызова настоящего диалога с полями "имя_пользователя", "пароль", "драйвер", "url_базы", и т.д.).

AVK>>Вот и расскажи как, используя джавовский рефлекшен, это реализовать.

VD>Я с ней не возился, но по описанию они мало чем отличается от Нэтовской. Атрибуты запихиваем в файл. Не очень красиво, но лучше чем паралельное тайп-инофо воротить.

А вдруг пользователь "наткнётся" на "интересный" текстовый файл и захочет немного "поправить положение вещей", что тогда? Хотя, конечно, такая информация нужна только разработчику в Design-time, но никак не конечному пользователю. :)

AVK>>Влад, в данном случае ты просто не в курсе. BeanInfo это вспомогательные классы.

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

AVK>>A bean implementor who wishes to provide explicit information about their bean may provide a BeanInfo class that implements this BeanInfo interface and provides explicit information about the methods, properties, events, etc, of their bean.

VD>Я цитаты драть не буду, но помню, что там еще были слова типа "если вам нужно вы можете сварганить все сами...".

Можно и самим. Конечно, если нам нужно. :)

AVK>>To minimize the resources used by a bean, the classes used by bean editors are loaded only when the bean is being edited. They are not needed while the bean is running in an application and therefore not loaded. This information is kept in what's called a bean-info (see BeanInfo).

VD>Ну, и? Нафига все это при наличие крутейшего решлекшона? Ироткр чибы понять, что getXxx и setXxx являются свойствами? Может проще было в этой Яве 2 свойства добавить с делегатами и не выпендриваться пудря мозги про конноы ОО?

Рефлекшн порой нужен бывает для реализации простейшего механизма "PLUG-IN" в Run-time. Поэтому в Java это не относится к чуду, но, скорее, как к данности этой технологии.

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

VD>Кто бы спрорил. Но лучши исходники и документация. :)

Исходники вместе с документацией == JavaDoc. :) Классно!

AVK>>Так сразу бы и говорил что тебе не нравится механизм BeanInfo, а не java beans. Особенно непонятно при чем здесь EJB.

VD>Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны.

EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит!

VD>>>Удобный... не удобный. Глваное необходимый. И идеологически лишний. К тому же эта дурная идеология говорит, что якобы компоненты начинаются с бобов, хотя любой скомпилированный класс в Яве является по существу компонентом.

AVK>>Влад, ты просто не в курсе.

VD>Я в курсе, что есть дефолтная реализация.

VD>>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает.
AVK>>Какой интерфейс?

VD>IComponent

VD>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. :( Причем в Яве худшая форма.

Ну, если любой класс считать компонентом, тогда да.
Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).

VD>>>Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные.
AVK>>Ну так BeanInfo и PropertyEditor тоже опциональные.

Добавлю: BeanInfo и расширенные PropertyEditor-ы нужны для "самостоятельного" руления IDE.

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

Да ну? Вот насмешил. :))) Рефлекшн даёт только то, что есть в классе. Нам самим решать, какие методы соответствуют тому или иному "свойству" и что они делают.
Всё остальное -- BeanInfo и расширенные PropertyEditors -- только помогают понять нам сущность класса и то, что хотел сказать нам разработчик класса, и работать с ним в Design-time.

VD>>> По умолчанию тоже PropertyEditor пользуется решлекшоном, а значит я могу вывести в него любой объект. И файл ему отдельный с надписью "А точно является компонентом" не нужен.
AVK>>В джаве все точно так же.

VD>Нет, в Яве по умолчанию создается умолчальная реализация всех этих BeanInfo и Introspector-ов, а уже она лезит к компонентам. Получается явная замена рефлекшона. Ольтернатива для получения информации о типах.

Да ничего не создаётся! Если нет BeanInfo и PropertyEditor-ов, то обходимся меньшим -- одним Рефлекшном и всё пучком.

VD>>> Еджиби же вообще один популизм. Все тоже самое можно было делать и без выделенного класса компонентов.
AVK>>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.

VD>Класное достижение!

EJB -- инфраструктура J2EE, фреймворк. Конкретные реализации EJB -- это уже бизнес-объекты в инфраструктуре J2EE.

VD>>>Вот это я называю неграмотным проектированием и ламерской реализацией. К тому же у них есть одна общая вещь... И те и другие компоненты. Хотя чем хуже все остальные???
AVK>>Проектирование то тут при чем? Просто не очень удачное название.

VD>Дык все эти Явы и Нэты спроектированы били...

AVK>>Где то в инете видел исследование — производительность современных компьютеров в 95% случаев избыточна.

VD>Это пускай читают, те кто програм никогда не писал. У меня на столе стоит Атлон ХаРэ 2000+ и я как то не часто замечаю что его производительность избыточна. Даже тот же ворд на серьезных документах тормозит.

VD>>>Пока есть только одно неоспоримое преимущество — легкая и быстрая реализация компонентов. Это особо актуально для бизнес-приложений, для остальных же все не так однозначно.
AVK>>Так бизнес-приложения это основные деньги. Завоевать рынок платформ для коробочного софта я думаю ни Sun ни MS особо не стремятся.

VD>Ты это MS или Sun-у раскажи. :) Вот они посмеются... Деньги есть везде. Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях.

AVK>>Ну а основное преимущество джавы и шарпа в скорости разработки.

VD>Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе.

AVK>>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.

VD>Это разные вещи. К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов.

VD>>> А если появятся грамотно реализованные шоблоны, то и этот фиговый листок отпадет за ненадобностью.
AVK>>Все это очень неоднозначно. Выиграем тут проиграем там.

VD>Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции.

AVK>>>>Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.
VD>>>Не очень то успешно. Только в одной нише (догадайся в кака?).
AVK>>Тем не менее коммерческий успех есть.

Только в России! :))

VD>Для борланда хватает, но Sun и MS за эти деньги даже пальцем не пошевельнули бы, так что все относитльно. Мы бы думаю были рады даже такому куску. :)

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

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

VD>Кстати если развивать перенос притчи, то MS получается вроде бога. А с ними лучше не спорить. (все же демогогия убедительная вещь) .
Нет бога окромя MS и Билл Гейтс пророк его.

VD>А-га! А в этом русском еще правла понасованы, да еще и компилятора нормального не прилогается. Один Ворд и тот тормозной интерпретатор.
Я себе компилятор русского языка представил. К примеру я говорю что стукну тебя по башке. Это все компилируется, запускается и ты ощущаешь что тебя стукнули по башке. Круть!

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


ZEN>>Я считаю: меньше размер -- меньше потенциальных ошибок в коде.
ZEN>>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?

Z2>Это вам кто-то из посвящённых на совместной пьянке рассказал? У меня лично SP1 beta1 для XP 117 Мб занимает...

Цитата (можно, конечно, пропустить мимо ушей:))):
"Microsoft выпустит Service Pack 1 для Windows XP досрочно

Недавно мы уже сообщали, что Microsoft предоставила тестерам первую бета-версию Service Pack 1 для Windows XP. Всезнающий сайт The Inquirer сообщил со ссылкой на информированные источники, что корпорация Microsoft решила выпустить первый Service Pack для ОС Windows XP досрочно. Это может произойдти еще до конца этого месяца.

Напомним, что выпуск самой ОС Windows XP состоялся в конце октября 2001 г. А уже в этом году Microsoft объявила, что Service Pack выйдет приблизительно в сентябре. Но, по всей видимости, много накопилось дополнений и особенно исправлений для исходной версии, что Microsoft решила поторопиться. Во всяком случае, в недавнем уведомлении о некорректной работе системного регистра, которая может привести к аварийному закрытию системы, пользователям предлагалось подождать для решения этой проблемы Service Pack 1. Это косвенно подтверждает досрочный выпуск этого продукта.

Как сообщается, Microsoft выпустит несколько версий Service Pack 1, и объем одного этого сборника заплаток составит целых 600 Мбайт. "
(http://www.interface.ru/fset.asp?Url=/microsoft/news/n020618527.htm)

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

ZEN>Так ли не обеспечивает?
Не обеспечивает. Для того и BeanInfo придумали.

ZEN> И всё ли нужно?
Все. На практике отделение метаданных от класса (как например в том же EJB) весьма геморойно. Все серьезные разработки на EJB которые я видел пользуют свои собственные генераторы бинов и деплоймент дескрипторов. Это показатель. Атрибуты могут эту проблему решить.

ZEN>Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи.
И все таки атрибуты это более элегантное решение. Впрочем в 1.5 что то подобное будет.

ZEN>EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит!
Очень оно слово такое, компонент, многозначное.


ZEN>Ну, если любой класс считать компонентом, тогда да.
ZEN>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.

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

IT>>Я заменял, заменяю и буду заменять все комы, которые только можно, на web-сервисы. У меня проблем с их скоростями нету, надо будет ещё пару процессоров в сервер воткнём. А вот deployment меня волнует серьёзно. После каждого изменения COM-объекта перегружать сотни рабочих станций мне никто не позволит. С remoting на клиентах тоже пока сильно не разбежишься, так что получается, что пока WS — спасение от всех зол.

AVK>А вот можно поподробнее — пачему ремотинг хуже веб-сервисов? У вас клиенты не дотнетовские?

Основное приложение не дот-нетовское. Это 2.75 уровневая система, написанная на MFC ещё года три-четыре назад, и она постоянно обновляется и поддерживается. Проблема в том, что вынуть шашки и с криками "За царя, за отечество!" переписать её ни за месяц, ни за два не удастся, да никто и не позволить всё сразу ломать. Здесь как раз к месту принцип "Лучшее — враг хорошего". Проблема ещё и в том, что с этой системой работают уже прошедшие обучение люди в разных штатах и странах. А это сотни рабочих станций, которые нужно проапгрейтить и поставить на них .NET.
В общем-то, работы ведутся, из всего этого барахла постепенно вынимаются кусочки и переносятся на аппликейшн сервера, местами начинаем применять браузерные технологии вместо обычного виндового UI, но до полного перехода на .NET ещё далеко.
Правда полно задач, которые не так критичны к деплойменту. Если например, программа планируется быть используемой только на двух-трех десятках машин, то вопрос об апгрейте даже не стоит.
К тому же ещё и девелоперов надо переучивать, хотя веб-сервисы народ берёт всего за пару дней, в отличии от COM, на который требуются недели, а иногда и месяцы.

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

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

ZEN>>Так ли не обеспечивает?
AVK>Не обеспечивает. Для того и BeanInfo придумали.

В Run-time BeanInfo излишне, вот и придумали -- "отделили мух от котлет".

ZEN>> И всё ли нужно?
AVK>Все. На практике отделение метаданных от класса (как например в том же EJB) весьма геморойно. Все серьезные разработки на EJB которые я видел пользуют свои собственные генераторы бинов и деплоймент дескрипторов. Это показатель. Атрибуты могут эту проблему решить.

Возможно. Не буду спорить. Но пока производители EJB-контейнеров не договорятся о единых способах работы с EJB и БД, такое -- чистая утопия.

ZEN>>Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи.
AVK>И все таки атрибуты это более элегантное решение. Впрочем в 1.5 что то подобное будет.

Посмотрим. По-моему, это всё равно, что засовывать JavaDoc в откомпилированный класс.:)

ZEN>>EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит!
AVK>Очень оно слово такое, компонент, многозначное.

Вот и вы согласились с многозначностью названия "компонент".

ZEN>>Ну, если любой класс считать компонентом, тогда да.
ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.

Классы менеджеров компоновки (Layouts) не обязаны иметь такой конструктор, потому что они -- "несовсем" компоненты. Возможно, такое ограничение на конструктор уже снято, однако в утилиту тестирования "BeanBox" такой компонент не положишь...:)

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

ZEN>>Ну, если любой класс считать компонентом, тогда да.
ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.

Специально посмотрел.
Только javax.swing.BoxLayout не имеет конструктора без параметров.
Все остальные стандартные Layout-ы имеют конструктор без параметров.

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

ZEN>>Ну, если любой класс считать компонентом, тогда да.
ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.

Специально посмотрел.
Только javax.swing.BoxLayout не имеет конструктора без параметров.
Все остальные стандартные Layout-ы имеют конструктор без параметров.

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

AVK>>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.

ZEN>Классы менеджеров компоновки (Layouts) не обязаны иметь такой конструктор, потому что они -- "несовсем" компоненты.
О том и речь. Для редактирования такого класса обязательно нужен его property editor чтобы знать какой параметр нужно передать конструктору. А в некоторых случаях (к примеру в случае long term persistence) это может происходить во время работы программы, а не только при дизайне.

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

А>Специально посмотрел.
А>Только javax.swing.BoxLayout не имеет конструктора без параметров.
А>Все остальные стандартные Layout-ы имеют конструктор без параметров.
Ну так не имеет же. Да и не только Layout, Size тоже вроде не имеет.

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

AVK>Ну в 10 раз только на очень определенных моментах. Суммарно раза в 1.5-2.

1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).

AVK>Time critical задачи нельзя решать ни на тогдашней джаве ни на теперешнем дотнете.

Начнем с тог что назвать "критичными ко времени". Реалтайм наверно пка рановато, но обычные приложения уже можно. Десктоп на нете работает неплохо. Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным. Нэт уже можно применять в большем классе задачь. Тоте же десктоп приложения я пока не отчаюсь создавать на Яве, а на Нэте влет. Я уже даже успел создать небольшое приложенице и мы его уже используем в штатном режиме для основной работы. Кстати я по нему должен еще статейку для RSDN Mag #1 дописать. Будет типа живой пример в картинках. :) Тормоза Явы во многом таятся не в слабостях джита, а в гупосте кодировщиков и архитекторов. Их желание получить полностью переносимый код доходило ранее до маразма. MS в этом отношении более сдержан. Есть переносимый серверный слой и клиент под виндовс. Плюсы: быстрый и качественный GUI, легкость реализации библиотеки, простота расширения (например, в EditBox не оказалось команды позиционирования к выделенной области текста и я с легкостью дописал такой метод использовав сообщения виндовс), ну, и для MS... он остается лидером хотя бы на рабочих станциях.

Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?

AVK>И еще — я уже не раз говорил, платформы вроде джавы и дотнета проектировались с прицелом не на кодера, а на дизайнера.

Ту это уже ерунда. То, что нужно упрощать процесс программирования/проектирования, тут никто не спорит. Работать за ними все равно тем же кодерам. Ту же яву стали использовать когда программист смог получить в руки удобные инструменты типа ЯваБилдера, а ведь язык не изменился почти...

AVK>В этом их принципиальное отличие от языков предыдущего поколения.

Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...

Высокоуровневые языки были давно. Возьми тот же VB. Можно плеваться сколько угодно, но ява в разы сложнее VB5-6, а приложения можно делать и на том, и на том.

AVK> Сейчас стало возможным пожертвовать эффективностью

Пожертвовать эффективностю можно было всегда. Вот толко все же лучше этого не делать. Я уже где-то говорил, что все достойные программы пишутся на пределе возмжностей железа. Если процессор станет быстрее программы прсто станут интеллектуальнее и функциональные. И вообще хватит про жизнь за 33 мегогерцами...

VD>>Ну, это они вроде неплохо и по именам отиличают.
AVK>Ну так это и есть java beans. А ты о чем подумал?

Давай канчать бестолково спорить.

В обычных бобах (ты сам об этом говорил) придуманы дополнительные средства — BeanInfo (и т.п.)

Давай так я перечислю свои утверждения и сделаю вывод, а ты уж сформулируй их критику.

1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).

2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.

3. BeanInfo является дополнительным стандартом определения информации о типах.

4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.

5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.

6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.

7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.

8. Компонентная модель Нэта красива, стройна и почти не противоречива.
"Почти" потому, как интерфейс компонент введен зря. Любой public класс Нэта является по сути компонентом (отвечает требованиям к компоненту).


VD>> В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют).
AVK>Классы гибче.

Эта гибкость портит компонентную модель. Что, по-моему, дароже.

AVK>>>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.
VD>>Можно, но за тебя его создадут.
AVK>Кто? Я в свое время изучал код Introspector — никто там ничего не создает. Сначала пытаются залезть через рефлекшн. А потом пытаются уже найти BeanInfo. Если не находят отдают то что удалось найти. Более того, можно заставить интроспектора игнорировать BeanInfo.

Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.

VD>> Главное, что ты не можешь переплюнуть логику компонента реализованного через нестандартные реализации этой лабуды, а занчит обязан все это читать через все эит BeanInfo.
AVK>Нет, BeanInfo нужен только дизайнеру. Так что ничего читать ты не обязан. Даже если ты пишешь свой дизайнер то используя интроспектор можешь не обращать внимания на все эти инфы. А можешь написать своего интроспектора который вместо классов будет использовать текстовые файлы.

Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.

AVK>Алгоритм в файл не запихнешь.

Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)

AVK> А потом наследство старой джавы — в plain text не очень то запихнешь, а xml-парсер появился только в 1.4.

Что наследство я не спорю. Но наследство очень левое. К тому же описание одного класса спокойно пихается в плоский файл формата:

a=b
c=f

Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.

AVK>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...

VD>>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя.
AVK>Можно. А учитывая то что есть исходники ВСЕЙ библиотеки можно сделать что угодно.

Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.

VD>> Т.е. даже появление атрибутов не приведет к изменению схемы. Ну, или снова будут гудеть о революции.
AVK>Приведет к появлению параллельной. А старую объявят deprecated.

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

AVK>Совершенно верно, проще. Но джава не дотнет — у нее уже не первая версия, надо обеспечивать совместимость.

Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед, то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.



VD>>>> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным.
AVK>>>Вот тут как раз и помогли бы исходники.
VD>>Кто бы спрорил. Но лучши исходники и документация. :)
AVK>Так на доку надо усилия прикладывать. Встречал в доке к дотнету фразу
AVK>This type supports the .NET Framework infrastructure and is not intended to be used directly from your code. ?
AVK>Думаешь откуда такое? В джаве подобного нет. Я думаю MS стремился как можно скорее релизнуть этот долгострой, и по причине нехватки времени не написал документацию или не проработал как следует интерфейсы, оставив их проработку на следующие версии.

Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.

По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги. То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))

VD>>Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны.
AVK>Ничего похожего на beaninfo там нет. Все спецификации свойств прописываются в специальном xml файле, который зовется deployment descriptor. Т.е. как раз то что ты предлагал. Вот пример для наглядности (большой потому что из реального приложения, меньше не нашел, а коцать времени нет)

Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?

AVK>>>Какой интерфейс?
VD>>IComponent
AVK>Ну почему же он ничего не делает? Он обеспечивает помощение Component в Container.

Нет он обеспечивает получение информации о контейнере. Но где в определение понятий компонент и контейнер слова о том что в контейнере нужен список объектов? Мжно было создать отдельный интерфейс типа IMyContainerInfo. Они кстити туда еще и диспоуз зафигачили.

Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.

AVK> Плюс является неким флажком указывающим что это компонент.

А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent. Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах?

VD>>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. :( Причем в Яве худшая форма.
AVK>Излишняя функциональность. Не всегда оно нужно.

Нет никакой излишности. Я уже говорил. IComponent формальность. По сути любой класс уже все умеет чтобы быть компонентом.

AVK>>>Ну так BeanInfo и PropertyEditor тоже опциональные.

Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo. Короче, жизнь по спецификации. Причем по плахой спецификации.

Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.


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

Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация! Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.

VD>>Получается явная замена рефлекшона. Ольтернатива для получения информации о типах.
AVK>Не альтернатива а недоделанность рефлекшена, не позволяющая его методами получить нужную информацию. Атрибуты были бы уместнее, но Sun до них не додумался. Теперь додумается :)

Я уже говорил, что решлекшон недоделан из-за недоделанноси явы. Нет свойств нет их описания.

Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.

Короче, мне кажется, что по существу ты со мной согласен, но почему то как и Sun в случае свойств и пречислений вредничаешь. Но я тоже вредный и буду стоять на своем, как бы это ни было больно. :)


AVK>>>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.
VD>>Класное достижение!
AVK>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.

Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:

AVK>У меня вот на работе Cel1000 не особо то тормозит. Видимо у тебя задачи такие.

И только у меня. Большинство коммерчиских задачь или полностью такие или имеют такие части.

Я думаю задача MS полностью заменить MSIL-ом ассемблер. Они отработали эту технику на VC7. Он теперь для оптимизации в .obj-ы не объектный код помещает, а свою версию MSIL-а! Далее становятся доступны оптимизации на уровня всего приложения. Вот только длл-ки мешаются. Так вот CLR потенциально может оптимизировать приложения на уровне запущенного процесса. При этом длл-ки уже являются не проблемой. Прикинь какие перспективы?!

Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)

AVK>А ворд тормозит совсем по другой причине. Я думаю на офисе MS оправдывает свою репутацию. :(

Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области. Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)

VD>>Ты это MS или Sun-у раскажи. :) Вот они посмеются... Деньги есть везде.
AVK>Сколько контор в штуках производит коробочный софт? Я думаю не очень много.

Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег, а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП). Теперь будет качать бабки и из бухгалтериий. :)

VD>>Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях.
AVK>Нельзя объять необъятное. Тебе достанется некий кусок рынка. И нужно выбрать оптимум чтобы сектор был с одной стороны достаточно велик чтобы приносить большие деньги но с другой стороны достаточно мал чтобы хватило сил его завоевать и удержать.

Это ты разсказываешь как фиговый игрок в стратегии (я не хочу оскорбть, я тоже фиговый). А MS с Sun это персоны борющиеся за первое место в абсолютном первенстве. У них просто под понятием рынок значится IT-сфера. Любой игрок средней руги знает, что есть тольо две победные стратегии. Первая — rush, игра на маментальные и полный снос протиника (как минимум ослабление противника до состояния, чтобы он не мог являться тебе конкурентоа). Втарая — захват ресурсов. Занял нишку... удержал... Противник занял нишку... а ты его из нее выбил. В конце концов у противника кончаются ресурсы и он отваливает. Все остальное тактика. Можно предукадать какую нишку будут выносить и сосредоточить свои войска в ней. Можно отдать нишку без боя, за то занять две других или одну но большую. А рержаться за одну дохлую нишу — это путь блохи. MS и Sun так играть не будут. Так что для победы им нужен тотальный (или привалирующий) контроль над всем уровнем. Блох они принцепяльно не будут сносить. Даже подкармливать будут и баит в союзника. Иначе MS сразу выиграет, а за выигрышь по законам штатов (да и всего остального мири) пологается расчленение. Мосмотри на мамашу Бэл. :)

VD>>Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе.
AVK>Скорость проектирования и качество полученных решений ниже. Качество я имею ввиду в плане дальнейшего развития.

Чушь, скорость проектирования вообще ут не причем. Пректирвание есть пректирование. Там все одинаково абстрактно. А программировать на VB даже быстрее чем на Яве. С ОО плохо, но для создания конечных систем это не смертельно. По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу. Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.

AVK>>>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.
VD>>Это разные вещи.
AVK>Тем не менее функционал темплейтов через рефлекшн реализуем.

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

VD>>К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов.
AVK>Типобезовасность реализуема и без них.

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

VD>>Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции.
AVK>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.

На ничего не будут. Ну, может улучшат малость. :)

На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.

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

Так что же страшного принесут шаблоны?

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

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

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

AVK>>Ну в 10 раз только на очень определенных моментах. Суммарно раза в 1.5-2.

VD>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.

AVK>>Time critical задачи нельзя решать ни на тогдашней джаве ни на теперешнем дотнете.

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

VD>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
Думаю лучше.

AVK>>И еще — я уже не раз говорил, платформы вроде джавы и дотнета проектировались с прицелом не на кодера, а на дизайнера.

VD>Ту это уже ерунда. То, что нужно упрощать процесс программирования/проектирования, тут никто не спорит. Работать за ними все равно тем же кодерам. Ту же яву стали использовать когда программист смог получить в руки удобные инструменты типа ЯваБилдера, а ведь язык не изменился почти...
Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.

AVK>>В этом их принципиальное отличие от языков предыдущего поколения.
VD>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
Не, это совсем не то.

VD>Высокоуровневые языки были давно. Возьми тот же VB. Можно плеваться сколько угодно, но ява в разы сложнее VB5-6, а приложения можно делать и на том, и на том.
А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.

AVK>> Сейчас стало возможным пожертвовать эффективностью

VD>Пожертвовать эффективностю можно было всегда. Вот толко все же лучше этого не делать. Я уже где-то говорил, что все достойные программы пишутся на пределе возмжностей железа. Если процессор станет быстрее программы прсто станут интеллектуальнее и функциональные. И вообще хватит про жизнь за 33 мегогерцами...
Все в деньги упирается. Экономически выгоднее написать менее эффективное приложение, но за меньший срок, с меньшим количеством ошибок и легче модифицируемое и купить более мощное железо. Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.

VD>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
А причем здесь это?

VD>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
Ну не так все серьезно. Но пока да, нет там этого.

VD>3. BeanInfo является дополнительным стандартом определения информации о типах.
Да.

VD>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
Нет. Только дополнительную — иконки, описания и т.п.

VD>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
Поскольку предпосылки в п.4 неверны то и этот пункт неверен.

VD>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
Да.

VD>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
Поскольку не все предпосылки верны то и вывод тоже не верен.

VD>8. Компонентная модель Нэта красива, стройна и почти не противоречива.

Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.


VD>>> В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют).
AVK>>Классы гибче.
VD>Эта гибкость портит компонентную модель. Что, по-моему, дароже.
Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.

VD>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo.
Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.

VD>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
Что то какая то демагогия получается. Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.

AVK>>Алгоритм в файл не запихнешь.
VD>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?

AVK>> А потом наследство старой джавы — в plain text не очень то запихнешь, а xml-парсер появился только в 1.4.

VD>Что наследство я не спорю. Но наследство очень левое. К тому же описание одного класса спокойно пихается в плоский файл формата:
VD>

VD>a=b
VD>c=f
VD>

А ты вспомни про то что бывают вложенные классы например. Или что тип свойств тоже может быть классом. Вот к примеру один из методов BeanInfo

 BeanInfo[] getAdditionalBeanInfo() 
 //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that 
 //provide additional information on the current bean.

VD>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
Что то мне то что ты предложил не кажется намного лучше.

AVK>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

VD>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность
А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.

VD> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.


VD>>>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя.
AVK>>Можно. А учитывая то что есть исходники ВСЕЙ библиотеки можно сделать что угодно.
VD>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.

VD>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед,
deprecated не означает что это не работает.

VD> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.

VD>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
Да какое там ноухау. Все это давно известно. JSP уже давно придумали.

VD>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги.
Ну уж PageParser то аналог в джаве имеет.

VD> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
Reverse engineering сто лет в обед.

VD>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
То есть как это не имеют? А к чему они тогда имеют?

VD>Они кстити туда еще и диспоуз зафигачили.
Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.

VD>Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.
Да нет в джаве никаких таких наворотов. Все там просто.

VD>А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent. Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах?
А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.

AVK>>>>Ну так BeanInfo и PropertyEditor тоже опциональные.

VD>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo.
Зачем? Все уже есть. Чем тебя интроспектор не устраивает?

VD>Короче, жизнь по спецификации. Причем по плахой спецификации.
Я так до сих пор и не понял — чем она конкретно плоха?

VD>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.

VD>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация!
Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.

VD>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.

VD>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.

AVK>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.
VD>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:

Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую. Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.

AVK>>У меня вот на работе Cel1000 не особо то тормозит. Видимо у тебя задачи такие.
VD>И только у меня. Большинство коммерчиских задачь или полностью такие или имеют такие части.
Странно, у меня вот тоже коммерческие задачи.

VD>Я думаю задача MS полностью заменить MSIL-ом ассемблер. Они отработали эту технику на VC7. Он теперь для оптимизации в .obj-ы не объектный код помещает, а свою версию MSIL-а! Далее становятся доступны оптимизации на уровня всего приложения. Вот только длл-ки мешаются. Так вот CLR потенциально может оптимизировать приложения на уровне запущенного процесса. При этом длл-ки уже являются не проблемой. Прикинь какие перспективы?!
Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?

VD>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR. Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.

AVK>>А ворд тормозит совсем по другой причине. Я думаю на офисе MS оправдывает свою репутацию. :(
VD>Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области.
Да. Но лучше от этого он не становится.

VD> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
А он пытается. Последний из могикан наверное.

VD>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег,
Там много денег. Это он лукавил.

VD> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП).
Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.

VD>Теперь будет качать бабки и из бухгалтериий. :)
Давно пора. Аксапту кстати будут переписывать под дотнет.


VD>Это ты разсказываешь как фиговый игрок в стратегии (я не хочу оскорбть, я тоже фиговый). А MS с Sun это персоны борющиеся за первое место в абсолютном первенстве. У них просто под понятием рынок значится IT-сфера. Любой игрок средней руги знает, что есть тольо две победные стратегии. Первая — rush, игра на маментальные и полный снос протиника (как минимум ослабление противника до состояния, чтобы он не мог являться тебе конкурентоа). Втарая — захват ресурсов. Занял нишку... удержал... Противник занял нишку... а ты его из нее выбил. В конце концов у противника кончаются ресурсы и он отваливает. Все остальное тактика. Можно предукадать какую нишку будут выносить и сосредоточить свои войска в ней. Можно отдать нишку без боя, за то занять две других или одну но большую. А рержаться за одну дохлую нишу — это путь блохи. MS и Sun так играть не будут. Так что для победы им нужен тотальный (или привалирующий) контроль над всем уровнем.
К счастью даже у MS не получится поиметь весь софтовый рынок. А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.

VD>Чушь, скорость проектирования вообще ут не причем. Пректирвание есть пректирование. Там все одинаково абстрактно.
Вот только абстракции все же должны опираться на особенности платформы. Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.

VD> А программировать на VB даже быстрее чем на Яве.
Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.

VD> С ОО плохо, но для создания конечных систем это не смертельно.
Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.

VD> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу.
Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.

VD> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.

AVK>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.
VD>На ничего не будут. Ну, может улучшат малость. :)
Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай. И это надо сделать во всей библиотеке. С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.

VD>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.

VD>Все что ты перечислил к делу не отностся. Все это всего лишь связано с рефлекшоном, и ты боишься, что решлекшон развалится потянув за собой остальное.
Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных. В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.

VD>Так что же страшного принесут шаблоны?
Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.

VD>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения.
Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.

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

VD>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает.
AVK>>>>Какой интерфейс?
VD>>>IComponent
AVK>>Ну почему же он ничего не делает? Он обеспечивает помощение Component в Container.

VD>Нет он обеспечивает получение информации о контейнере. Но где в определение понятий компонент и контейнер слова о том что в контейнере нужен список объектов? Мжно было создать отдельный интерфейс типа IMyContainerInfo. Они кстити туда еще и диспоуз зафигачили.

VD>Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.

AVK>> Плюс является неким флажком указывающим что это компонент.

VD>А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent.

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


VD>Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах?
VD>>>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. Причем в Яве худшая форма.

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


VD>Нет никакой излишности. Я уже говорил. IComponent формальность. По сути любой класс уже все умеет чтобы быть компонентом.

Да не такая уж и формальность.
У компонентов такая фунуциональность, что без дополнительного интерфейса не обойтись.
Компонент должен иметь ссылку на контейнер чтобы в нем ковыряться, и просматривать другие компоненты из того же контейнера. Из тройки IComponent,ISite,IContainer бесполезным можно назвать только ISite от этого уровня косвенности еще можно было бы избавиться, можно было бы дать компоненту ссылку на сам IContainer.

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


ZEN>Всего: 36.92Mb -- вот сколько счастья для обычного пользователя!!!!


Люди, да че вы давитесь за 30Метров ?
Места на диске у узера нет ?
Так снесите все игрушки, сразу под гиг освободится...
А если еще инспекция по защите авторских прав нагрянет,
так в лучшем случае ничего кроме Виндов и оффиса не останется.

По моему, главно что бы было быстро

А узеру от программы нужны две вещи, форма ввода и отчеты... и чем проще, тем лучше...
А все остальное — это от лешего.

Все это ИМХО.

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

VD>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
AVK>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.

В смысле в сравнении с VC7, Intel C++ или Delphi 6.

К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.

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

Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...

VD>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
AVK>Думаю лучше.

Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)

AVK>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.

Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.

AVK>>>В этом их принципиальное отличие от языков предыдущего поколения.
VD>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
AVK>Не, это совсем не то.

Ну, тебе видней. ;)

AVK>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.

А там обычно этго и не нужно. Тем более, что я это уже делал. :)

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

Ну, по этим показателям VB6 будет бить Яву еще долго. :)))

AVK> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.

Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).

В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.

VD>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
AVK>А причем здесь это?

При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.

VD>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
AVK>Ну не так все серьезно. Но пока да, нет там этого.

Дык, это вроде и породило спор. :???:

VD>>3. BeanInfo является дополнительным стандартом определения информации о типах.
AVK>Да.

VD>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
AVK>Нет. Только дополнительную — иконки, описания и т.п.

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

VD>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
AVK>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.

См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)

VD>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
AVK>Да.

VD>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
AVK>Поскольку не все предпосылки верны то и вывод тоже не верен.

Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.

VD>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.

AVK>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.

На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.

VD>>Эта гибкость портит компонентную модель. Что, по-моему, дароже.
AVK>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.

На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.

VD>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
AVK>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo.
AVK>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.

Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?

VD>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
AVK>Что то какая то демагогия получается.

А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.

AVK>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.

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

AVK>>>Алгоритм в файл не запихнешь.
VD>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
AVK>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?

Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?

AVK>А ты вспомни про то что бывают вложенные классы например.

Выложи их описание в отдельный файл.

AVK>Или что тип свойств тоже может быть классом.

Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.

AVK>Вот к примеру один из методов BeanInfo

AVK>

AVK> BeanInfo[] getAdditionalBeanInfo() 
AVK> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that 
AVK> //provide additional information on the current bean. 
AVK>

Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(

VD>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
AVK>Что то мне то что ты предложил не кажется намного лучше.

Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.

AVK>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

VD>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность
AVK>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.

Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.

VD>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
AVK>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.

Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/

VD>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
AVK>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.

Заметь! Значит их нужно корежить. :)

VD>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед,
AVK>deprecated не означает что это не работает.

Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)

VD>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
AVK>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.

Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.

VD>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
AVK>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.

JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.

VD>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги.
AVK>Ну уж PageParser то аналог в джаве имеет.

Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?

VD>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
AVK>Reverse engineering сто лет в обед.

Назови хоть один продукт который моддерживает двунаправленную генерацию кода на нескольких языках и при этом мозволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей.

VD>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
AVK>То есть как это не имеют? А к чему они тогда имеют?

К частной реализации одного класса (BeanInfo).

VD>>Они кстити туда еще и диспоуз зафигачили.
AVK>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.

Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.

AVK>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.

Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm

VD>>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo.
AVK>Зачем? Все уже есть. Чем тебя интроспектор не устраивает?

Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(

VD>>Короче, жизнь по спецификации. Причем по плахой спецификации.
AVK>Я так до сих пор и не понял — чем она конкретно плоха?

Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.

VD>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
AVK>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.

Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.

VD>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация!
AVK>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.
Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.

VD>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
AVK>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.

Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(

VD>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
AVK>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.

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

AVK>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.
VD>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:

AVK>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.

Лучше одна новая.

AVK>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.

Компонентная модель там не храмая. Многим нарвится и сама библиотека.

AVK>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?

В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.

VD>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
AVK>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.

Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.

AVK> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.

Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...

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

В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)

VD>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
AVK>А он пытается. Последний из могикан наверное.

Вообще-то все конкуренты живы. Даже Лексикон. :)

VD>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег,
AVK>Там много денег. Это он лукавил.

Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?

VD>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП).
AVK>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.

Ну, это ты SAP. :)

VD>>Теперь будет качать бабки и из бухгалтериий. :)
AVK>Давно пора. Аксапту кстати будут переписывать под дотнет.

Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...

AVK>К счастью даже у MS не получится поиметь весь софтовый рынок.

А-га. Но понадкусывать может. :)

AVK>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.

Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.

AVK>Вот только абстракции все же должны опираться на особенности платформы.

Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.

AVK>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.

Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.

VD>> А программировать на VB даже быстрее чем на Яве.
AVK>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.

Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?

VD>> С ОО плохо, но для создания конечных систем это не смертельно.
AVK>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.

А ты знаешь на чем тот же SAP создан?

VD>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу.
AVK>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.

Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.

VD>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
AVK>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.

Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.

AVK>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.
VD>>На ничего не будут. Ну, может улучшат малость. :)
AVK>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.

Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.

AVK> И это надо сделать во всей библиотеке.

Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)

AVK> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.

Дык, на то они и монстры!

VD>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
AVK>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.

Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.

AVK>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.

Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?

AVK> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.

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

VD>>Так что же страшного принесут шаблоны?
AVK>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.

Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.

VD>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения.
AVK>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.

Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.

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

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

VD>>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
AVK>>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.

VD>В смысле в сравнении с VC7, Intel C++ или Delphi 6.

VD>К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.

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

VD>Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...

VD>>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
AVK>>Думаю лучше.

VD>Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)

AVK>>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.

VD>Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.

AVK>>>>В этом их принципиальное отличие от языков предыдущего поколения.
VD>>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
AVK>>Не, это совсем не то.

VD>Ну, тебе видней. ;)

AVK>>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.

VD>А там обычно этго и не нужно. Тем более, что я это уже делал. :)

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

VD>Ну, по этим показателям VB6 будет бить Яву еще долго. :)))

AVK>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.

VD>Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).

VD>В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.

VD>>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
AVK>>А причем здесь это?

VD>При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.

VD>>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
AVK>>Ну не так все серьезно. Но пока да, нет там этого.

VD>Дык, это вроде и породило спор. :???:

VD>>>3. BeanInfo является дополнительным стандартом определения информации о типах.
AVK>>Да.

VD>>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
AVK>>Нет. Только дополнительную — иконки, описания и т.п.

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

VD>>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
AVK>>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.

VD>См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)

VD>>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
AVK>>Да.

VD>>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
AVK>>Поскольку не все предпосылки верны то и вывод тоже не верен.

VD>Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.

VD>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.

AVK>>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.

VD>На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.

VD>>>Эта гибкость портит компонентную модель. Что, по-моему, дароже.
AVK>>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.

VD>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.

VD>>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
AVK>>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo.
AVK>>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.

VD>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?

VD>>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
AVK>>Что то какая то демагогия получается.

VD>А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.

AVK>>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.

VD>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?

AVK>>>>Алгоритм в файл не запихнешь.
VD>>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
AVK>>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?

VD>Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?

AVK>>А ты вспомни про то что бывают вложенные классы например.

VD>Выложи их описание в отдельный файл.

AVK>>Или что тип свойств тоже может быть классом.

VD>Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.

AVK>>Вот к примеру один из методов BeanInfo

AVK>>

AVK>> BeanInfo[] getAdditionalBeanInfo() 
AVK>> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that 
AVK>> //provide additional information on the current bean. 
AVK>>

VD>Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(

VD>>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
AVK>>Что то мне то что ты предложил не кажется намного лучше.

VD>Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.

AVK>>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

VD>>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность
AVK>>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.

VD>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.

VD>>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
AVK>>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.

VD>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/

VD>>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
AVK>>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.

VD>Заметь! Значит их нужно корежить. :)

VD>>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед,
AVK>>deprecated не означает что это не работает.

VD>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)

VD>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
AVK>>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.

VD>Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.

VD>>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
AVK>>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.

VD>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.

VD>>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги.
AVK>>Ну уж PageParser то аналог в джаве имеет.

VD>Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?

VD>>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
AVK>>Reverse engineering сто лет в обед.

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

VD>>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
AVK>>То есть как это не имеют? А к чему они тогда имеют?

VD>К частной реализации одного класса (BeanInfo).

VD>>>Они кстити туда еще и диспоуз зафигачили.
AVK>>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.

VD>Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.

AVK>>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.

VD>Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:

VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm
VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm

VD>>>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo.
AVK>>Зачем? Все уже есть. Чем тебя интроспектор не устраивает?

VD>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(

VD>>>Короче, жизнь по спецификации. Причем по плахой спецификации.
AVK>>Я так до сих пор и не понял — чем она конкретно плоха?

VD>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.

VD>>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
AVK>>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.

VD>Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.

VD>>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация!
AVK>>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.
VD>Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.

VD>>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
AVK>>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.

VD>Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(

VD>>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
AVK>>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.

VD>Это же как не дублируют, если в них та же информация но в другом виде? Да если бы они всегда дублировали, это было бы пол биды. А ведь можно учудить... я это уже сто раз говорил.

AVK>>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.
VD>>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:

AVK>>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.

VD>Лучше одна новая.

AVK>>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.

VD>Компонентная модель там не храмая. Многим нарвится и сама библиотека.

AVK>>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?

VD>В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.

VD>>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
AVK>>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.

VD>Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.

AVK>> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.

VD>Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...

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

VD>В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)

VD>>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
AVK>>А он пытается. Последний из могикан наверное.

VD>Вообще-то все конкуренты живы. Даже Лексикон. :)

VD>>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег,
AVK>>Там много денег. Это он лукавил.

VD>Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?

VD>>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП).
AVK>>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.

VD>Ну, это ты SAP. :)

VD>>>Теперь будет качать бабки и из бухгалтериий. :)
AVK>>Давно пора. Аксапту кстати будут переписывать под дотнет.

VD>Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...

AVK>>К счастью даже у MS не получится поиметь весь софтовый рынок.

VD>А-га. Но понадкусывать может. :)

AVK>>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.

VD>Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.

AVK>>Вот только абстракции все же должны опираться на особенности платформы.

VD>Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.

AVK>>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.

VD>Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.

VD>>> А программировать на VB даже быстрее чем на Яве.
AVK>>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.

VD>Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?

VD>>> С ОО плохо, но для создания конечных систем это не смертельно.
AVK>>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.

VD>А ты знаешь на чем тот же SAP создан?

VD>>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу.
AVK>>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.

VD>Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.

VD>>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
AVK>>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.

VD>Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.

AVK>>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.
VD>>>На ничего не будут. Ну, может улучшат малость. :)
AVK>>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.

VD>Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.

AVK>> И это надо сделать во всей библиотеке.

VD>Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)

AVK>> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.

VD>Дык, на то они и монстры!

VD>>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
AVK>>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.

VD>Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.

AVK>>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.

VD>Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?

AVK>> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.

VD>А никто полиморфности отменять не будет. Появятся универсальные типы, которые тоже смогут быть полиморфными. Но не только динамически, но и статически (на уровне парометризации). Очень даже может быть, что все это будет сильно отличаться от шаблнов С++-а.

VD>>>Так что же страшного принесут шаблоны?
AVK>>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.

VD>Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.

VD>>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения.
AVK>>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.

VD>Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.

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

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

VD>>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
AVK>>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.

VD>В смысле в сравнении с VC7, Intel C++ или Delphi 6.

VD>К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.

Тесты Java2 vs. Delphi:
http://www.beep.ru/~izen/projects/projects.html
См. "JavaTest" и "DelphiTest"
Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других.
Результаты в вычислениях с плав.точкой просто потрясают.

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

VD>Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...

VD>>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
AVK>>Думаю лучше.

VD>Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)

Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.

AVK>>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.

VD>Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.

AVK>>>>В этом их принципиальное отличие от языков предыдущего поколения.
VD>>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
AVK>>Не, это совсем не то.

VD>Ну, тебе видней. ;)

AVK>>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.

VD>А там обычно этго и не нужно. Тем более, что я это уже делал. :)

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

VD>Ну, по этим показателям VB6 будет бить Яву еще долго. :)))

AVK>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.

Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности.

VD>Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).

VD>В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.

VD>>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).

Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом. JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :))


VD>При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.

Все классы -- это компоненты -- да, но только в общем смысле этого слова.

VD>>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
AVK>>Ну не так все серьезно. Но пока да, нет там этого.

Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе.

VD>Дык, это вроде и породило спор. :???:

VD>>>3. BeanInfo является дополнительным стандартом определения информации о типах.
AVK>>Да.

VD>>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
AVK>>Нет. Только дополнительную — иконки, описания и т.п.

BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию.

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

Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:)

VD>>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
AVK>>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.

Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection.

VD>См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)

VD>>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
AVK>>Да.

VD>>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
AVK>>Поскольку не все предпосылки верны то и вывод тоже не верен.

На вкус и цвет...
Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел.

VD>Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.

VD>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.

У вас такой вкус...:)

AVK>>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.

VD>На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.

VD>>>Эта гибкость портит компонентную модель. Что, по-моему, дароже.
AVK>>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.

VD>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.

Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других.
Спорить о красоте, в этом случае, глупо.

VD>>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
AVK>>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo.
AVK>>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.

VD>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?

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

VD>>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
AVK>>Что то какая то демагогия получается.

VD>А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.

AVK>>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.

VD>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?

Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента.

AVK>>>>Алгоритм в файл не запихнешь.
VD>>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
AVK>>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?

VD>Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?

AVK>>А ты вспомни про то что бывают вложенные классы например.

VD>Выложи их описание в отдельный файл.

AVK>>Или что тип свойств тоже может быть классом.

VD>Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.

AVK>>Вот к примеру один из методов BeanInfo

AVK>>

AVK>> BeanInfo[] getAdditionalBeanInfo() 
AVK>> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that 
AVK>> //provide additional information on the current bean. 
AVK>>

VD>Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(

VD>>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
AVK>>Что то мне то что ты предложил не кажется намного лучше.

VD>Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.

AVK>>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

VD>>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность
AVK>>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.

VD>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.

BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте. Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения.

VD>>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
AVK>>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.

VD>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/

Мне VCL не нравится. Но я же не кричу об этом на всю улицу.

VD>>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
AVK>>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.

VD>Заметь! Значит их нужно корежить. :)

VD>>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед,
AVK>>deprecated не означает что это не работает.
VD>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)

deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций.

VD>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.

Когда это я менял тему?

AVK>>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.

VD>Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.

VD>>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
AVK>>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.

VD>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.

Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.
А где MS? "Редактируйте" res-файлы только мышкой в дизайнере!
А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй.

VD>>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги.
AVK>>Ну уж PageParser то аналог в джаве имеет.

VD>Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?

VD>>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))

Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта.

AVK>>Reverse engineering сто лет в обед.

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

Rational Rose, Together.

VD>>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
AVK>>То есть как это не имеют? А к чему они тогда имеют?

VD>К частной реализации одного класса (BeanInfo).

VD>>>Они кстити туда еще и диспоуз зафигачили.
AVK>>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.

VD>Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.

AVK>>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.

VD>Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:

VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm
VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm

VD>>>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo.
AVK>>Зачем? Все уже есть. Чем тебя интроспектор не устраивает?

VD>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(

Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне.

VD>>>Короче, жизнь по спецификации. Причем по плахой спецификации.
AVK>>Я так до сих пор и не понял — чем о
на конкретно плоха?

VD>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.

Не дублирование, но дополнение. Как вы это всё ещё не поймёте?

VD>>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
AVK>>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.

VD>Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.

VD>>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация!
AVK>>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.
VD>Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.

VD>>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
AVK>>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.

VD>Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(

VD>>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
AVK>>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.

VD>Это же как не дублируют, если в них та же информация но в другом виде? Да если бы они всегда дублировали, это было бы пол биды. А ведь можно учудить... я это уже сто раз говорил.

AVK>>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.
VD>>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:

AVK>>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.

VD>Лучше одна новая.

AVK>>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.

VD>Компонентная модель там не храмая. Многим нарвится и сама библиотека.

Мне нет. Swing на порядок стройнее и продуманней.

AVK>>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?

Есть PDA с pure-JavaOS, работающие на Java-процессоре aJ-100 (по последним новостям из osp.ru http://www.osp.ru/news/hard/2002/07/03_01.htm
"100% Java
03.07.2002
Версия для печати
Выскажите свое мнение

В компании aJile Systems разработана базовая модель коммуникационного устройства, которую можно использовать в основе телефонов и PDA. Ядро устройства — однокристальный процессор aJ-100, способный без дополнительного преобразования исполнять байт-код Java. Имеются также 8 Мбайт статической оперативной памяти и 8 Мбайт флэш-памяти. В комплект поставки входит набор средств разработки. Устройство управляется Java OS и содержит ряд приложений: браузер, менеджер личной информации, клиент электронной почты, MP3-проигрыватель, средство мгновенного обмена SMS-сообщениями и игры. Имеется возможность создания защищенных разделов, позволяющих исполнять загружаемые из Internet Java-приложения без опасений за целостность системы. Базовая модель коммуникатора поддерживает стандарты GPRS и CDMA 2000. Как утверждают в aJile, реализуемая аппаратно процессором aJ-100 виртуальная машина Java работает в 10 раз быстрее большинства программных.

InfoWorld, США"

VD>В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.

VD>>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
AVK>>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.

VD>Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.

AVK>> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.

VD>Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...

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

VD>В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)

VD>>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
AVK>>А он пытается. Последний из могикан наверное.

VD>Вообще-то все конкуренты живы. Даже Лексикон. :)

VD>>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег,
AVK>>Там много денег. Это он лукавил.

VD>Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?

VD>>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП).
AVK>>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.

VD>Ну, это ты SAP. :)

VD>>>Теперь будет качать бабки и из бухгалтериий. :)
AVK>>Давно пора. Аксапту кстати будут переписывать под дотнет.

VD>Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...

AVK>>К счастью даже у MS не получится поиметь весь софтовый рынок.

VD>А-га. Но понадкусывать может. :)

AVK>>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.

VD>Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.

AVK>>Вот только абстракции все же должны опираться на особенности платформы.

VD>Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.

AVK>>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.

VD>Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.

VD>>> А программировать на VB даже быстрее чем на Яве.
AVK>>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.

VD>Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?

VD>>> С ОО плохо, но для создания конечных систем это не смертельно.
AVK>>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.

VD>А ты знаешь на чем тот же SAP создан?

VD>>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу.
AVK>>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.

VD>Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.

VD>>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
AVK>>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.

VD>Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.

AVK>>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.
VD>>>На ничего не будут. Ну, может улучшат малость. :)
AVK>>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.

VD>Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.

AVK>> И это надо сделать во всей библиотеке.

VD>Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)

AVK>> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.

VD>Дык, на то они и монстры!

VD>>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
AVK>>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.

VD>Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.

AVK>>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.

VD>Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?

AVK>> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.

VD>А никто полиморфности отменять не будет. Появятся универсальные типы, которые тоже смогут быть полиморфными. Но не только динамически, но и статически (на уровне парометризации). Очень даже может быть, что все это будет сильно отличаться от шаблнов С++-а.

VD>>>Так что же страшного принесут шаблоны?
AVK>>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.

VD>Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.

VD>>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения.
AVK>>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.

VD>Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.

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

ZEN>Тесты Java2 vs. Delphi:
ZEN>http://www.beep.ru/~izen/projects/projects.html
ZEN>См. "JavaTest" и "DelphiTest"
ZEN>Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других.
ZEN>Результаты в вычислениях с плав.точкой просто потрясают.

К сожалению теста для Дельфи там нет (дэд-линк). Но и без этого теста я могу сказать (базируясь на наших тестах), что Дельфи будет быстрее во всех тестах (кроме строк) даже при сравнении с Ява 1.3. Если брать не вылизанные тесты, а реальные программы, то разныв в пользу Дельфи даже увеличится, потому что кодируя на Яве мало кто утруждает себя расстановкой сэйледов и других файналов.

ZEN>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.

За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.


AVK>>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.

ZEN>Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности.

Ява вообще не применима для реального времени, так как ее реализация GC дает разные временные характиристики на одной и той же задаче. Реалное время — это прежде всего гарантированные временные задержки.

ZEN>Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом.

Нельзя. Это спецификация.

ZEN>JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :))

Это как раз подтверждает мои слова. Обойтись можно, но в Sun сочли, что ради иконки можно запороть всю компонентную модель.


ZEN>Все классы -- это компоненты -- да, но только в общем смысле этого слова.

У этого слова частных смыслов я незнаю. То что Sun называет ява бобами, все остальные вот уже около 10 лет называют контролами.

ZEN>Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе.

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

ZEN>BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию.

Насколько я помню, там можно получить список методов. Может я заблуждаюсь?

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

ZEN>Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:)

Это ты о пасажире или о пути? ;)

ZEN>Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection.

Дык BeanInfo если что эмулируется на рефлекшоне, так что можно всегда через него.

ZEN>На вкус и цвет...
ZEN>Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел.

Тебя раздржает не ОО-модель дельфи. А структура их библиотеки. Это азные вещи. Сама ОО-модель в Дельфи проста и последовательна. Хотя слишком проста и совсем недокументирована.

VD>>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.

ZEN>У вас такой вкус...:)

Я сравниваю две модели.


VD>>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.

ZEN>Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других.
ZEN>Спорить о красоте, в этом случае, глупо.

А я и не отрицаю, что это мое мнение. И соглашаться никого не заставляю. ;)

VD>>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?

ZEN>Голословное утверждение. Приведите пример, когда срочно необходим BeanInfo, когда без него не обойтись.

Всегд где нужна информация о типах для ява боба. Иначе работать будет не все.

VD>>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?

ZEN>Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента.

Свойств в Ява вообще нет. В Нэте они есть и "понимать" через решлекшон их как раз плюнуть.

VD>>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.

ZEN>BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте.

Воветую глянуть на Нэт. Там таких примочек нет, а красочность ни чуть не хуже. Правда там атрибуты есть, но файкт остается фактом.

ZEN>Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения.

Практика показывает, что можно и без них.

VD>>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/

ZEN>Мне VCL не нравится. Но я же не кричу об этом на всю улицу.

Извени, а что ты делаешь? ;)

Не будем говорить кто это был... Но это был слоненок! :)

VD>>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)

ZEN>deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций.

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

VD>>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.

ZEN>Когда это я менял тему?

См. свой спор на счет сравнения размеров JRE и .Net Runtime. В середине разговора, ты акуратно превел тему на клиентский компьютер, так и не ответив зачем на нем вообще нужна Ява.

VD>>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.

ZEN>Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.

Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.

ZEN>А где MS? "Редактируйте" res-файлы только мышкой в дизайнере!

Не понял. :???:

ZEN>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй.

Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.

ZEN>Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта.

Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.

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

ZEN>Rational Rose, Together.

Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.

VD>>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(

ZEN>Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне.

Не, теперь я скорее буду использовать .Net.

VD>>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.

ZEN>Не дублирование, но дополнение. Как вы это всё ещё не поймёте?

То что в BeanInfo больше информации я не спорю. Но там есть откровенный дубляж. Для любого кто хочет использовать компонентную модель, хочет чтобы она была просто, последовательна и непротиворечива. Дублях это точно не здорово.

VD>>Компонентная модель там не храмая. Многим нарвится и сама библиотека.

ZEN>Мне нет. Swing на порядок стройнее и продуманней.

Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.

ZEN>InfoWorld, США"

Ну, на пресрелизы достаточно и ссылки.