Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kuj, Вы писали:
G>>>>Но при этом Java тормознее .NET. C>>>Почему? По тестам — обратный результат. kuj>>Да покажите тесты-то. C>К примеру: http://www.shudo.net/jit/perf/
Во-первых где код?
Большенство тестов, которые показывают что кто-то там быстрее написаны с использованием техник оптимизации на одном языке и без них на другом.
Во-вторых так .NET версии 1.1.
С тех пор он побыстрее стал.
В-третьих там в основном математика, для которой гораздо лучше написать один раз неуправляемый код на C.
Здравствуйте, Cyberax, Вы писали:
G>>>>Но при этом Java тормознее .NET. C>>>Почему? По тестам — обратный результат. kuj>>Да покажите тесты-то. C>К примеру: http://www.shudo.net/jit/perf/
Зашибись. Еще более древнего найти не мог?
kuj>>Особенно интересно посмотреть на тесты с активным использованием дженериков. ;> C>Если не использовать примитивные контейнеры — разницы в скорости особой нет.
Ну я не знаю я не сравнивал. Но дженерики в основном как-раз во всяких контейнерах и используются.
Здравствуйте, hattab, Вы писали:
H>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт.
G>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен.
H>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой.
Зашибись. А если у объекта два разных владельца?
G>>Даже костыль для этого дела придумали, DataModule вроде зовется.
H>Это как раз один из способов выделения бизнес-логики.
Это один из примеров почему делфи самое место в том месте, где она сейчас находится — в топке.
H>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>Ну это и ежу понятно. G>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать.
H>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая.
Ну ка, ну ка, покажи нам вменяемую реализацию MVC или MVP под делфи. Слабо? ;]
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Можно и на формочки, а можно и ручками. В чем проблема то? Типа для шарпа в VS не так G>>Не так G>>При всем желании SQLConnection на формочку не положишь. H>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт.
Ути какой шустрый.
В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии.
То есть TComponent в делфи нужен для гуя.
G>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой.
Бред говоришь.
Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
G>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>Это как раз один из способов выделения бизнес-логики.
Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public.
Почему нельзя обычный класс написать?
H>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>Ну это и ежу понятно. G>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать. H>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая.
Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
Здравствуйте, gandjustas, Вы писали:
H>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>Ути какой шустрый. G>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>То есть TComponent в делфи нужен для гуя.
TComponent нужен для поддержки дизайн-тайма. Учи матчасть.
G>>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой. G>Бред говоришь. G>Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
Еще раз подумай над тем, что я написал.
G>>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>>Это как раз один из способов выделения бизнес-логики. G>Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public. G>Почему нельзя обычный класс написать?
Кто тебе сказал, что нельзя?
H>>>>Говнокод есть следствие логических ошибок и неправильного проектирования, коие техническими средствами не решаются. Так яснее? G>>>Ну это и ежу понятно. G>>>Другое дело что сама IDE в делфи подталкивает такие ошибки совершать. H>>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая. G>Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
Я жутко не люблю повторяться, но приходится... (... от которых ничего не спасет)
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>Ути какой шустрый. G>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>То есть TComponent в делфи нужен для гуя. H>TComponent нужен для поддержки дизайн-тайма. Учи матчасть.
Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
G>>>>Даже костыль для этого дела придумали, DataModule вроде зовется. H>>>Это как раз один из способов выделения бизнес-логики. G>>Это костыль для формоклепателей, да еще и нарушающий инкапсуляцию ведь все компоненты — public. G>>Почему нельзя обычный класс написать? H>Кто тебе сказал, что нельзя?
Ну если такой костыль придумали — значит нельзя было.
Здравствуйте, gandjustas, Вы писали:
H>>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>>Ути какой шустрый. G>>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>>То есть TComponent в делфи нужен для гуя. H>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует.
G>>>Почему нельзя обычный класс написать? H>>Кто тебе сказал, что нельзя? G>Ну если такой костыль придумали — значит нельзя было.
Здравствуйте, hattab, Вы писали:
G>>>>Кроме того в делфи, в отсуствие нормального GC, время жизни компонент привязывается к времени жизни Owner, который обычно является формой, на которой компонент размещен. H>>>Я тебе больше скажу, в любой иерархии объектов, жизнь оных зависит от их владельцев. В любой. G>>Бред говоришь. G>>Я IoC-контейнер использую и сам задаю время жизни нелокальных объектов независимо от того где они используются.
H>Еще раз подумай над тем, что я написал.
Не надо проецировать проблемы гомносреды программирования (делфи) на нормальные. В дотнет компоненты это обычные классы и как всякий обычный экземпляр обычного класса вовсе не обязан иметь владельца.
H>>>Засунуть логику в баттон-евенты можно в любой среде. Это ошибка логическая. G>>Чтобы развеять свое убеждение посмотри на ASP.NET MVC.
H>Я жутко не люблю повторяться, но приходится... (... от которых ничего не спасет)
Иди лучше RTFMь про нормальные фреймворки вместо того, чтоб восхвалять тут мертвечину.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Невизуальные компоненты можно размещать на формах в VS? Можно. Вопрос закрыт. G>>>>Ути какой шустрый. G>>>>В WPF на форму вообще можно положить любой объект, без всяких TComponent и прочей порнографии. G>>>>То есть TComponent в делфи нужен для гуя. H>>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
H>RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует.
То есть пришли к тому с чего начали: вся компонентая модель делфи направлена на гуй (кидание компонентов на формочку).
Здравствуйте, gandjustas, Вы писали:
H>>>>TComponent нужен для поддержки дизайн-тайма. Учи матчасть. G>>>Да ну, и какие же члены TComponent нужны для дизайн-тайма? И для чего нужны остальные члены?
H>>RTTI он получает наследуясь от TPersistent. Весь остальной функционал направлен на реализацию компонентной модели, которую собственно дизайнер и использует. G>То есть пришли к тому с чего начали: вся компонентая модель делфи направлена на гуй (кидание компонентов на формочку).
Ты под гуем дизайн-тайм подразумеваешь, что ли? Если так, тогда все верно: компонентая модель служит для "создания компонентов через гуй".
Здравствуйте, Cyberax, Вы писали:
D>>Гы! Сериализация сериализации рознь. XML-сериализация в том же .NET существует с незапамятных времён. Однако к XAML'у это не имеет никакого отношения. C>Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов.
Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю.
D>>Модель всегда отделена от её визуального представления, как минимум на логическом уровне. На то она и модель собственно.
C>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text".
И в Swing'е всё ровно также: getText() и телемаркет.
C>Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно.
Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ???
C>Аналогично и в WPF — только там для этого используется обобщённый DependencyObject.
Так вот ничего аналогичного. В WPF для связывания с моделями данных приложения доступны все свойства соответствующих элементов UI, причём связывание включает поддержку выражений, и можно "бродить" как по модели, так и по дереву UI. И при всей этой мощи, в 90% случаев сия связь задаётся всего одной строкой в XAML-представлении. И "реализовывать поверх чего угодно" ничего не нужно.
D>>И задача состоит не в отделении, бо оно аксиома, а в обеспечении мощных и в то же время выразительных, простых и удобных механизмов связи модели с её конкретной визуализацией. Их и предоставляет WPF — binding'и для dependency property. Подобных вещей в Swing'е просто не существует.
C>В Swing'е это реализуется с помощью виртуальных моделей.
У jgoodies-binding с binding'ом WPF общее только одно — слово "binding".
C>В WPF оно всё сделано более обобщённо и красиво, но суть та же самая осталась.
Приехали. В WinForms вон тоже есть binding, и даже в WebForms есть. Суть та же, говно только...
C>>>отход от оконной модели интерфейса. D>>М-м-м... А где это в Swing'е-то можно увидеть ??? C>Что именно?
"Отход от оконной модели интерфейса". В Ваших постингах я его так и не вижу.
C>В Swing'е рисованием компонентов занимается look&feel, который отделён от самого контрола и может меняться (в том числе в runtime'е).
Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
C>В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации.
Гы! Так JavaFX и появился после того, как в Sun увидели WPF. Однако до WPF ему пока ещё очень далеко, в том числе и концептуально. И это понимают, бо штучка позиционируется прежде всего в роли новой UI-платформы для J2ME.
D>>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например. C>Лучше явно выделять такие сервисы в сервисные классы.
Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом.
Здравствуйте, drol, Вы писали:
C>>Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов. D>Ну так что это за аналоги-то ? Я вот лично таких не знаю. Есть вещи в которых присутствуют разные отдельные куски идей стоящих за XAML, но чтобы всё это было грамотно сведено в одном месте — такого не припоминаю.
Их много разных: http://java-source.net/open-source/xml-user-interface-toolkits — есть и с возможностью байндинга отдельных свойств.
C>>Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text". D>И в Swing'е всё ровно также: getText() и телемаркет.
Это не более чем удобный аксессор.
C>>Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно. D>Так это не та модель. Это модель элемента UI. А точнее её часть, бо его остальные ~100 свойств в неё почему-то не входят. И зачем оно нужно ???
За большую часть остальных свойств отвечает:
1) Система layout'ов, внешняя по отношению к контролу.
2) Look&Feel.
D>Так вот ничего аналогичного. В WPF для связывания с моделями данных приложения доступны все свойства соответствующих элементов UI, причём связывание включает поддержку выражений, и можно "бродить" как по модели, так и по дереву UI. И при всей этой мощи, в 90% случаев сия связь задаётся всего одной строкой в XAML-представлении. И "реализовывать поверх чего угодно" ничего не нужно.
Это всё есть в SWING'е, даже брожение по дереву контролов с помощью декларативного языка — http://www.opensymphony.com/ognl/html/LanguageGuide/introduction.html или http://commons.apache.org/jxpath//users-guide.html#Nested_Bean_Property_Access
D>Ну занимается. Ну может меняться. Да, жизнь разработчиков Swing Team из Sun, видимо, облегчилась. Может ещё каким героям скиноваяния тоже стало чуть веселее. А вот мне, как обычному разработчику, совершенно по-барабану. Бо подход к рендерингу UI при этом совершенно не изменился. И написать свой look&feel к Swing'у, даже для пары control'ов, это куча работы. Тогда как заскинить control в WPF не представляет никаких затруднений. Более того, для этого в большинстве случаев я даже практически не нужен. Всё может сделать и непосредственно дизайнер.
Специально для тебя сделали skinnable L&F'ы...
C>>В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации. D>Гы! Так JavaFX и появился после того, как в Sun увидели WPF. Однако до WPF ему пока ещё очень далеко, в том числе и концептуально. И это понимают, бо штучка позиционируется прежде всего в роли новой UI-платформы для J2ME.
JavaFX они варили достаточно долго, аж с 2004-го года. Оно больше как конкурент Silverlight/Flash.
C>>Лучше явно выделять такие сервисы в сервисные классы. D>Они и так выделены. Extension-методы есть методы статических классов. Если Вас напрягает instance-ный синтаксис вызова, то Вы можете вызывать их и обычным образом.
Если вызывать обычным способом — то они и не нужны.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, March_rabbit, Вы писали:
CC>>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>>В чем непреодолимая трудность то? M_>>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? CC>Мне всё равно что там в линухе. CC>Я спрашиваю конкретно под винду: что именно мешает создать отдельные маленькие .NET Runtime дистрибутивы?
я не микрософт, но предположу: никому не надо. Лишняя работа программистов, тестеров и еще кучи людей.
Здравствуйте, MxKazan, Вы писали:
O>>>>Cω это шо такое? Си с яйцами? (: kuj>>Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно... MK>Копи-паст рулит
Здравствуйте, KipDblK, Вы писали:
O>>>>>Cω это шо такое? Си с яйцами? (: kuj>>>Тьфу блин... где эту кнопку омега на клавиатуре найти-то? Лазить в alt-коды чтоли постоянно... MK>>Копи-паст рулит
KDK>Это суть технологии?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность. G>>Для этого можно и реляционную базу прикрутить. C>Нельзя. Можно было бы — прикрутил.
Расскажи это ребятам из Quest Software (кстати привет бывшим коллегам, если они тут есть , команде разработчиков MS Exchange — это только те, кого сходу вспомнил. Так что не стоит недостаток собственных знаний выдавать за недостаток технологии...
Здравствуйте, koandrew, Вы писали:
C>>Нельзя. Можно было бы — прикрутил. K>Расскажи это ребятам из Quest Software (кстати привет бывшим коллегам, если они тут есть , команде разработчиков MS Exchange — это только те, кого сходу вспомнил. Так что не стоит недостаток собственных знаний выдавать за недостаток технологии...
Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах.
Здравствуйте, Cyberax, Вы писали:
C>Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах.
Ещё раз медленно: ставишь AD, расширяешь его схему как тебе нужно — и дело в шляпе. Что тут непонятного?
Здравствуйте, koandrew, Вы писали:
C>>Ещё раз медленно: у меня НЕ стояла задача как-то хранить данные. Стояла задача как-то сделать LDAP-интерфейс для сторонней системы. Как его сделать — было не особо важно. Хоть на DBF-файлах и bash-скриптах. K>Ещё раз медленно: ставишь AD, расширяешь его схему как тебе нужно — и дело в шляпе. Что тут непонятного?
Нельзя было использовать AD (я же написал, что оно должно было работать параллельно с AD). Ты думаешь, мы такие тупые, что не догадались бы воткнуть схему в AD и наслаждаться жизнью?
