Почему обработка событий в Java такая многословная, это дает какие-то преимущества по сравнению с .Net и Qt, или просто ошибка проектирования Java???

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

S>Почему обработка событий в Java такая многословная, это дает какие-то преимущества по сравнению с .Net и Qt, или просто ошибка проектирования Java???

Количество написанных символов кода не означают многословность или немногословность.
По моему, в .NET для адекватной обработки событий надо похожим образом переопределять методы add и remove, хотя можно и полагаться на фреймворк.

В принципе — ничья.

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

S>Почему обработка событий в Java такая многословная, это дает какие-то преимущества по сравнению с .Net и Qt, или просто ошибка проектирования Java???

Нет. Это исправление ошибок архитектуры AWT.

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

S>Почему обработка событий в Java такая многословная, это дает какие-то преимущества по сравнению с .Net и Qt, или просто ошибка проектирования Java???

Модель Qt очень многословная. Посмотри хотя бы на код, который qmake генерирует.

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

S>Почему обработка событий в Java такая многословная, это дает какие-то преимущества по сравнению с .Net и Qt, или просто ошибка проектирования Java???
Вопрос вкуса. В Java, в принципе, с трюком Listener+Adapter логически схожие события объединяются в один интерфейс. На практике, особой разницы я не замечаю.

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

M>Модель Qt очень многословная. Посмотри хотя бы на код, который qmake генерирует.
Не qmake а moc.
Это не модель многословная, а реализация. Ты же не смотришь какие генерируются vt_tables компилятором в случае вирт. множ. наследования.

M>>Модель Qt очень многословная. Посмотри хотя бы на код, который qmake генерирует.
_>Не qmake а moc.
_>Это не модель многословная, а реализация. Ты же не смотришь какие генерируются vt_tables компилятором в случае вирт. множ. наследования.

Сорри. Действительно moc. Давно за Qt не брался.

И, имхо, некорректно сравнивать vt_tables с кодом, генерируемым moc'ом. Код, генерируемый moc'ом — это всего лишь автоматизация процесса, который надо было бы выписывать ручками каждый раз, не будь этого moc'а.

Здравствуйте, Mamut, Вы писали:
M>И, имхо, некорректно сравнивать vt_tables с кодом, генерируемым moc'ом. Код, генерируемый moc'ом — это всего лишь автоматизация процесса, который надо было бы выписывать ручками каждый раз, не будь этого moc'а.
Почему? moc = meta object compiler. Перефразируя:
vt_tables, генерируемые компилятром — это всего лишь автоматизация процесса, который надо было бы выписывать ручками каждый раз, не будь этого компилятора.

M>>И, имхо, некорректно сравнивать vt_tables с кодом, генерируемым moc'ом. Код, генерируемый moc'ом — это всего лишь автоматизация процесса, который надо было бы выписывать ручками каждый раз, не будь этого moc'а.
nau>Почему? moc = meta object compiler. Перефразируя:

Да они его могли как угодно назвать Хоть uetm — universal event translation mechanism Он все равно создает код на чистом С++

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



Думаю, можно написать механизм slot'ов и для C# и для Java с таким же moc'ом. Менее многословным от этого этот механизм не станет, имхо

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

M>>>И, имхо, некорректно сравнивать vt_tables с кодом, генерируемым moc'ом. Код, генерируемый moc'ом — это всего лишь автоматизация процесса, который надо было бы выписывать ручками каждый раз, не будь этого moc'а.
nau>>Почему? moc = meta object compiler. Перефразируя:

M>Да они его могли как угодно назвать Хоть uetm — universal event translation mechanism Он все равно создает код на чистом С++

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

M>

M>Думаю, можно написать механизм slot'ов и для C# и для Java с таким же moc'ом. Менее многословным от этого этот механизм не станет, имхо

За то, на мой взгляд, будет более удобным. Пишешь connect(...) и все. А в Java приходится много букв писать!

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


S>За то, на мой взгляд, будет более удобным. Пишешь connect(...) и все. А в Java приходится много букв писать!

Зато гибко и понятно. А много буков... Use ide. Ессно, это не означает, что нужно использовать редактор формочек(последний рульный умер вместе с Жбилдер 10), да и события есть далеко не только от визуальных элементов(СОВСЕМ не только от них. События от драйверов ведь дизайнером не нарисуешь ). Руками, но тот же эклипс нагенерит 95% кода, идея, думаю, не меньше(давно не пользовал). Тебе нужно будет только писать логику в обработчике. А на символы забей. Что они тебе?

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

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


S>>За то, на мой взгляд, будет более удобным. Пишешь connect(...) и все. А в Java приходится много букв писать!

E__>Зато гибко и понятно. А много буков... Use ide. Ессно, это не означает, что нужно использовать редактор формочек(последний рульный умер вместе с Жбилдер 10), да и события есть далеко не только от визуальных элементов(СОВСЕМ не только от них. События от драйверов ведь дизайнером не нарисуешь ). Руками, но тот же эклипс нагенерит 95% кода, идея, думаю, не меньше(давно не пользовал). Тебе нужно будет только писать логику в обработчике. А на символы забей. Что они тебе?
Я считаю, что модель Qt хороша. Потому, что редактор форм с layout'ами — Хорошая Вещь. А Qt'шный moc — это грубо говоря способ реализации делегатов + rtti на С++, такой себе "закат солнца вручную", и, возможно, в Java без него можно обойтись.
То, что я вижу сейчас в Eclipse — не то. Qt'шный дизайнер форм генерит в итоге XML. Из него можно сгенерировать C++ код uic'ом, но можно и подргузить XML (форму) в runtime. Очень удобно. Как это сделать в Swing'e, SWT? Эклипс же просто генерит кучу UI кода.
На мой взгляд, чем лаконичнее код без потери читабельности/понятности — тем лучше. Тут вроде Qt уделывает всех.
Кстати, было бы здорово иметь кроссплатформенную GUI либу на D. Ей реально небыло бы конкурентов среди компилируемых вариантов при правильной реализации. Желательно с нативными виджетами. Возможно, unix-world потихоньку бы и перешел на нормальный компилируемый ЯП при реализации GUI с С++ и, прости господи, С.

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

nau>Я считаю, что модель Qt хороша. Потому, что редактор форм с layout'ами — Хорошая Вещь. А Qt'шный moc — это грубо говоря способ реализации делегатов + rtti на С++, такой себе "закат солнца вручную", и, возможно, в Java без него можно обойтись.
nau>То, что я вижу сейчас в Eclipse — не то. Qt'шный дизайнер форм генерит в итоге XML. Из него можно сгенерировать C++ код uic'ом, но можно и подргузить XML (форму) в runtime. Очень удобно. Как это сделать в Swing'e, SWT? Эклипс же просто генерит кучу UI кода.
Layout'ы — это основная фишка в SWING/SWT, так что оно там тоже есть. А вот генерация XML — это еще вопрос. Не очень понятно нужен ли он.

В IDEA/Eclipse GUI designer'ах можно сделать класс с описанием GUI и подгружать его в рантайме при необходимости (точно так же, как и XML). Ну и при желании возможна и генерация XML — все известные мне редакторы форм сохраняют данные в XML-файлах, и их можно при желании компилировать в рантайме. Еще есть и вообще чистые XML-подходы: http://jfcml.sourceforge.net/ и прочие.

Меня в Java единственно раздражает несовместимость форматов дизайнеров форм между разными IDE. Но это, в принципе, не так сложно исправить.

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

C>Layout'ы — это основная фишка в SWING/SWT, так что оно там тоже есть. А вот генерация XML — это еще вопрос. Не очень понятно нужен ли он.

Это вообще безбашенная штука. Мне их дико не хватало при разработке GUI на шарпе.

C>В IDEA/Eclipse GUI designer'ах можно сделать класс с описанием GUI и подгружать его в рантайме при необходимости (точно так же, как и XML). Ну и при желании возможна и генерация XML — все известные мне редакторы форм сохраняют данные в XML-файлах, и их можно при желании компилировать в рантайме. Еще есть и вообще чистые XML-подходы: http://jfcml.sourceforge.net/ и прочие.

Да чего только под java нет... Но лично мне подход xml для дизайнера кода не очень.

C>Меня в Java единственно раздражает несовместимость форматов дизайнеров форм между разными IDE. Но это, в принципе, не так сложно исправить.

Вообще, модель позволяет писать без дизайнеров вообще. У нас свои лайоуты и свой лукэндфил. Дизайнеры не используем, все в коде, спринг конфиге, и пропертях(для user-friendly настроек, автоматом грузящихся с сервера) Результат, как по мне, неплохой

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

E__>Вообще, модель позволяет писать без дизайнеров вообще. У нас свои лайоуты и свой лукэндфил. Дизайнеры не используем, все в коде, спринг конфиге, и пропертях(для user-friendly настроек, автоматом грузящихся с сервера) Результат, как по мне, неплохой
У вас тут GUI достаточно простой Кроме того, он нестатический, так что идеально подходит для автоматической генерации.

Мы просто обнаружили, что для всяческих формочек проще использовать дизайнер. Собственно, IDEAвский дизайнер нас удовлетворяет на 100%.

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

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

E__>>Вообще, модель позволяет писать без дизайнеров вообще. У нас свои лайоуты и свой лукэндфил. Дизайнеры не используем, все в коде, спринг конфиге, и пропертях(для user-friendly настроек, автоматом грузящихся с сервера) Результат, как по мне, неплохой
C>У вас тут GUI достаточно простой

Там есть посложнее элементы, это главная . Но да, бывает сложнее, я не спорю.

C>Кроме того, он нестатический, так что идеально подходит для автоматической генерации.

??
Не понял, в чем суть.

C>Мы просто обнаружили, что для всяческих формочек проще использовать дизайнер. Собственно, IDEAвский дизайнер нас удовлетворяет на 100%.

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

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

C>>Кроме того, он нестатический, так что идеально подходит для автоматической генерации.
E__>??
E__>Не понял, в чем суть.
Блин, не надо с утра отвечать на RSDN

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

C>>Мы просто обнаружили, что для всяческих формочек проще использовать дизайнер. Собственно, IDEAвский дизайнер нас удовлетворяет на 100%.
E__>Хм.. 4 года назад идеевский дизайнер был.. как бы это помягче сказать.. в полной ж... После этого не пробовал, не довелось. В принципе, верю. Идея вообще штука отличная.
Не знаю, layout'ы рисует нормально, контролы позволяет бросать — а больше мне особо много и не надо

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

C>>>Кроме того, он нестатический, так что идеально подходит для автоматической генерации.
E__>>??
E__>>Не понял, в чем суть.
C>Блин, не надо с утра отвечать на RSDN

C>Я хотел сказать, что ваш GUI идеально подходит для ручного создания, без автоматической генерации из редактора формочек.

Да там динамика реализуется двумя способами: компоненты, сами меняющие состояние, и контроллер flow, меняющий панельки. Так что хз. Но интерфейс не самый стандартный, это да, потому и рисуем руками.

C>Вопрос вкуса. В Java, в принципе, с трюком Listener+Adapter логически схожие события объединяются в один интерфейс.

Ага, и чтобы обработать "OnClose" надо заодно писать пустой обработчик на OnSize. Удобно офигенно. Единственная причина, почему так следали заключается в том, что это академически правильно с точки зрения ООП.

В QT система — явный костыль, и, как все костыли,создаёт серьёзные ограничения. Например, шаблонные классы принципиально не могут использовать системы SLOT/SIGNAL. Так что система в .NET (которая ранее была в VCL) выглядит наиболее удобной: потомки используют перегрузку функций, что позволяет контролировать вызов оригинальной функции (которая, как правило, просто генерит эвенты), классы-пользователи подписываются на события.

Ага, когда класс формы должен обработать OnClose, надо унаследоваться от ComponentListener, реализовать метод OnClose (а заодно — OnResize, который не будет ничего делать), и потом добавить this в список слушателей себя же.
Офигенно.