Здравствуйте, Mamut, Вы писали:
H>>>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>>>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
H>>Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
M>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
Я для кого писал:
MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
Обрати внимание на выделенное.
M>>>Зачем мне реализовывать методы QueryInterface, _AddRef и _Release, если я их все равно в данном случае не буду использовать? Или это идеология такая — писать код ради кода? Почему я не могу написать:
H>>Ты можешь и не использовать, а вот компилятор использует, ссылки считает да интерфейсы получает...
M>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов? Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface)
M>>> function someMethod : AnsiString
M>>>end
M>>>
H>>Можешь написать и так, только наследуйся от TInterfacedObject.
M>Если. Любой. Интерфейс. Наследуется. От. IUnknown. Зачем мне явно указывать, что мы реализуем IUnknown, если мы его все равно реализуем
Выше смотри.
M>>>Захотели реализовать IUnknown? Пожалуйста: M>>>
M>>>MyInterface : Interface
M>>> function someMethod : AnsiString
M>>>end
M>>>MyClass : Class(TObject, MyInterface, IUnknown)
M>>> function someMethod : AnsiString
M>>> function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
M>>> function _AddRef: Integer; stdcall;
M>>> function _Release: Integer; stdcall;
M>>>end
M>>>
M>>>Зачем плодить лишние сущности?
H>>Это ты сейчас предлагаешь писать лишнее Наследуйся от TInterfacedObject и всех делов.
M>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав G>>В чем?
H>Вот в этом: H>
H>>Да ни одна библиотека не в состоянии покрыть все потребности...
H>Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
Еще раз. Сторонние компоненты есть всегда. Просто потому что их можно писать.
Для делфи существует рынок компонент, то есть на написании компонент многие зарабатывают деньги.
Для .NET и Java такого практически нет. Почти все полезные компоненты ((N)Hibernate, Spring(.NET) и прочие) бесплатны. Хотя это даже не компоненты.
G>>В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей. H>Угу. И Девэкспрессов нету для .Net'а... В общем твое упорство говорит только об одном -- тебе не приходилось писать ничего сложнее стандартных базаморд.
Я кроме работы с БД много чего писал, но сторонние компоненты практически не использовал.
H>>>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64 G>>Напиши лучше. H>Мне то оно зачем? Не я это тут рекомендовал к ознакомлению...
Ксатти ты хоть проччитал что за компоненты использованы в Paint.NET? Это только для работы с разными форматами файлов — аименьшая часть всего приложения.
H>Вот! Теперь список требований для модерна в студию, плиз
Перечитай топик сначала, уже все написано.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, squid, Вы писали:
H>>>Как оказалось, оно и в ActiveX работает
S>>может пофиксили...
H>У меня версия от 2002 года... Можешь сказать в чем заключался твой фикс, я в исходниках погляжу
лень сравнивать
чото с инициализацией GDI+ и отсутствием вызова шатдауна изза бага.
H>>>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
S>>EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
H>Я же написал, changes.txt. Да, 2.3.4 с 2004 года обновлений небыло, но обновлялось оно почти каждый месяц.
т.е. ты согласен что 5 лет нет обновлений это нормально?? ну нет там поддержи новых фич, не отрицай.
H> Можешь еще здесь глянуть, хидеры аж от 2007 года.
лишний раз подтверждает мою позицию — хидеры ДОЛЖНЫ быть официальные.
тут спорить больше небуду, тебя не убедить
я не один новый проект на дельфе не начну как-раз из-за вечных тупняков Борладна и забивания на просьбы разработчиков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: наши менеджеры памяти самые менеджеристые менеджеры
H>>>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>>Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
H>Я фигею с таких доводов... Мы исполнители... Тебе заказчик банку с вазелином покажет, капустой похрустит и...? С заказчиком нужно диалог вести и, по меньшей мере, понять причины таких требований. Не, ну если тебе нравится получать деньги за переписывание того, что уже существует... в MS прямая дорога, они вот собираются IE8 с нуля писать (точнее уже собрались и пишут).
Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
M>>>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>>>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
M>>Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
H>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
Как это следует из моих слов? И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
H>>>>>Расширяется не IUnknown. Расширяется MyInterface декларацией IUnknown.
M>>>>Зачем? Что нам это дает, кроме необходимости писать дополнительный код, который все равно нигде не нжен и нигде не участвует?
H>>>Что значит зачем? Правило языка. Любой интерфейс, если не указано иное, наследуется (но наследование осуществляется расширением декларации) от IInterface.
M>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>Я для кого писал: H>
H>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>Обрати внимание на выделенное.
И? Какой смысл? M>>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
H>Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов?
Зачем?
H> Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
А что, не тот же результат? С точки зрения COM'а — абсолютно тот же
M>>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
H>Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
Как это неверно? Любой объект, реализующий любой интерфейс в дельфи обязан стать COM-объектом. Кривизна реализации в Дельфи от этого не избавляет.
Кстати, ты так и не объяснил, что значит фраза "интерфес MyInterface расширяется интерфейсом IUnknown". Какой от этого практичский смысл
Смешные вы, ей богу, столько времени толочь воду в ступе...
По порядку:
2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
Microsoft прилагает реальный усилия, постоянно дополняя функциональность .NET Framework. В 1.0 не было даже managed средств для вывода звука. В 3.5 появились: O/RM, MVC для ASP и т.д. В одной из следующих версий обещали наконец стандартный IoC-контейнер.
Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
Тем не менее, использование сторонних сборок в .NET практика довольно-таки стандартная. Например, как O/RM nHibernate все еще на целую голову впереди Linq to SQL и EntityFramework. ASP MVC, хотя и развиваяется семимильными шагами, тем не менее все еще несколько уступает тому же Castle Monorail.
Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework), во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем "создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
Re[29]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, gandjustas, Вы писали:
H>>>>Ну надо же Ладно, кончай придуриваться. Согласись, что был не прав G>>>В чем?
H>>Вот в этом: H>>
H>>>Да ни одна библиотека не в состоянии покрыть все потребности...
H>>Только .NET и Java почему-то покрывает. Есть конечно некоторые нестандартные решения, о рынке говорить не приходится.
G>Еще раз. Сторонние компоненты есть всегда. Просто потому что их можно писать. G>Для делфи существует рынок компонент, то есть на написании компонент многие зарабатывают деньги. G>Для .NET и Java такого практически нет. Почти все полезные компоненты ((N)Hibernate, Spring(.NET) и прочие) бесплатны. Хотя это даже не компоненты.
Ты чего с очевидными вещами споришь??? Я тебе ссылку давал.
G>>>В .NET такого нету. Стандартная библиотке покрывает большенство необходимостей. H>>Угу. И Девэкспрессов нету для .Net'а... В общем твое упорство говорит только об одном -- тебе не приходилось писать ничего сложнее стандартных базаморд. G>Я кроме работы с БД много чего писал, но сторонние компоненты практически не использовал.
Ну я и говорю, что это лишь показывает "сложность" тех проектов...
H>>>>Посмотри на свой любимый Paint.Net, в окошке About. Три сторонних библиотеки заюзано для такого скромненького проекта. Кстати, эта гхм... хранит MRU миниатюры в реестре, да еще и в виде строки base64 G>>>Напиши лучше. H>>Мне то оно зачем? Не я это тут рекомендовал к ознакомлению... G>Ксатти ты хоть проччитал что за компоненты использованы в Paint.NET? Это только для работы с разными форматами файлов — аименьшая часть всего приложения.
Ну я в курсе, что его наибольшая часть это FW на моем диске Только как это отрицает факт задействования сторонних библиотек/компонентов? И еще скажи, какой изощренный мегамозг умудрился хранить PNG-миниатюры в реестре (и это, блин, при развитых средствах работы с конфигами )
H>>Вот! Теперь список требований для модерна в студию, плиз G>Перечитай топик сначала, уже все написано.
Тут кроме нападок читать нечего. От вас, господа, критики по делу как небыло так и нет, сплошь "костыль" да "костыль"
Здравствуйте, squid, Вы писали:
H>>>>Как оказалось, оно и в ActiveX работает
S>>>может пофиксили...
H>>У меня версия от 2002 года... Можешь сказать в чем заключался твой фикс, я в исходниках погляжу
S>лень сравнивать
Я так и думал
H>>>>Судя по changes.txt, обновляют они ее чуть не каждый месяц...
S>>>EVR и прочих вистовских вещей как небыло так и нет. хотя один чувак на форуме частичный порт выкладывал. где ты обновления узрел я не знаю. стабильных версий не видно а качать билды непонятной стабильности с CVS — глупо. последней версии 2.3.4 уже пару лет. как минимум.
H>>Я же написал, changes.txt. Да, 2.3.4 с 2004 года обновлений небыло, но обновлялось оно почти каждый месяц.
S>т.е. ты согласен что 5 лет нет обновлений это нормально?? ну нет там поддержи новых фич, не отрицай.
Ну да, давно не обновлялось... Очевидно, впрочем, что Борланду это было нужно еще меньше чем прогдигам...
H>> Можешь еще здесь глянуть, хидеры аж от 2007 года.
S>лишний раз подтверждает мою позицию — хидеры ДОЛЖНЫ быть официальные.
S>тут спорить больше небуду, тебя не убедить
Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
Re[27]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, Mamut, Вы писали:
H>>>>Да мне тут и про вояк говорили... Вот только говорители даже обосновать такие требования не могут
M>>>Мы — исполнители. Заказчик может требовать, что хочет. Блин, я в рассылке по jQuery (Javascript!) наткнулся на вопросы, связаные с тем, что для гос. сайта был прямой запрет на использование каких-лио сторонних Javascript-компонентов.
H>>Я фигею с таких доводов... Мы исполнители... Тебе заказчик банку с вазелином покажет, капустой похрустит и...? С заказчиком нужно диалог вести и, по меньшей мере, понять причины таких требований. Не, ну если тебе нравится получать деньги за переписывание того, что уже существует... в MS прямая дорога, они вот собираются IE8 с нуля писать (точнее уже собрались и пишут).
M>Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
Т.е. ты считаешь, что написание твоего велосипеда с последующим всесторонним тестированием, отладкой, доводкой, да еще в условиях изменяющихся требований будет стоить дешевле нежели ревью кода? Насмешил.
M>>>>>Юникод — это базовое требование, в отличие от XML-RPC и прочих
H>>>>Что значит базовое? В языке оно есть очень давно. В гуй-библиотеке не поддерживается пока. Неприятный факт? Конечно неприятный. Но для кого? Для корпоративной системы его наличие или отсутствие не упирается ни в одну точку (а Delphi на что ориентирована?).
M>>>Угу. Особнно, если в этой системе надо поддерживать турецкий, английский и русский. Good luck, как говорится.
H>>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
M>Как это следует из моих слов?
Очень просто: ты критикуешь необходимость самостоятельного написания поддержки Юникода в VCL, но при этом тебя не пугает перспектива написания движка аля Трайдент.
M>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
Здравствуйте, Mamut, Вы писали:
M>>>В пятый раз прошу: обьсни мне, что ты понимаешь под словом "расширяется" и что ты понимаешь под словом "наследуется"
H>>Я для кого писал: H>>
H>>MyInterface будет содержать декларации методов от IUnknown (но эти декларации будут его декларациями), плюс свои собственные. Мамут, тебе не надоело? Я уже сто раз это написал...
H>>Обрати внимание на выделенное.
M>И? Какой смысл?
Ты безнадежен
M>>>Тогда зачем мне явно указывать, что тот или иной объект реализует IUnknown, если мы и так его реализуем?
H>>Что значит и так реализуем? А ты не считаешь, что MyInterface может иметь собственную реализацию этих методов?
M>Зачем?
За хлебом. Посмотри на исходник TComObject, может поймешь зачем...
H>> Или ты думаешь, что получив от объекта IUnknown и дернув его метод _AddRef (например) ты имеешь тот же результат, что и в случае дергания метода _AddRef от интерфейса IMyInterface полученного от того же объекта?
M>А что, не тот же результат? С точки зрения COM'а — абсолютно тот же
Зависит от реализации. Результат может отличаться.
M>>>Зачем? Зачем мне дополнительно еще указывать то, что мы реализуем IUnknown, если мы его так или иначе реализуем?
M>>>И разве любой класс, реализующий любой интерфейс не становится автоматически COM-объектом? Если да, то тогда любой интерфейс в Дельфи является COM-совместимым
H>>Объекты класса реализующего IUnknown становятся COM-объектами. А вот твое утверждение на COM-совместимость интерфейсов неверно.
M>Как это неверно? Любой объект, реализующий любой интерфейс в дельфи обязан стать COM-объектом. Кривизна реализации в Дельфи от этого не избавляет.
Что, на второй круг собрался? Мамут, я устал с тобой спорить...
Re[30]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
H>Ты чего с очевидными вещами споришь??? Я тебе ссылку давал.
Я тебе говорю: компоненты есть. Но это не рынок, это по большей части наколеночные поделки, кроме десятка серьезных фреймворков, которые пришли из Java.
Ты мне: ну смотри же, есть компоненты!
H>Ну я и говорю, что это лишь показывает "сложность" тех проектов...
В чем-то ты прав. На C# (и .NET вообще) все проекты гораздо проще, чем аналогичные на делфи.
Здравствуйте, kuj, Вы писали:
kuj>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
WCF это не оно
kuj>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
VCL глупо сравнивать с FW, ибо VCL не есть фреймвок. С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
kuj>Microsoft прилагает реальный усилия, постоянно дополняя функциональность .NET Framework. В 1.0 не было даже managed средств для вывода звука. В 3.5 появились: O/RM, MVC для ASP и т.д. В одной из следующих версий обещали наконец стандартный IoC-контейнер. kuj>Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
Да я только рад этому Опухнет в конец и лопнет раньше, чем доберется до моего HDD
kuj>Тем не менее, использование сторонних сборок в .NET практика довольно-таки стандартная. Например, как O/RM nHibernate все еще на целую голову впереди Linq to SQL и EntityFramework. ASP MVC, хотя и развиваяется семимильными шагами, тем не менее все еще несколько уступает тому же Castle Monorail.
kuj>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
kuj>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
Коли уж цифрами бросаешься, давай и ссылки.
kuj>"создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
Не нужно мне приписывать свою интерпретацию моих слов Если решил цитировать, цитируй до буквы.
kuj>Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
kuj>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
Иногда лучше жевать.
kuj>Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
kuj>Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
А этот бред даже комментировать не буду...
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
Здравствуйте, hattab, Вы писали:
M>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>Можно обойтись класс-хелперами и перехватом API.
"Перехват API" это что еще за зверь?
Кстати, откуда информация о том, что Paint.NET хранит thumbnails в системном реестре Windows?
Здравствуйте, gandjustas, Вы писали:
H>>Ты чего с очевидными вещами споришь??? Я тебе ссылку давал. G>Я тебе говорю: компоненты есть. Но это не рынок, это по большей части наколеночные поделки, кроме десятка серьезных фреймворков, которые пришли из Java. G>Ты мне: ну смотри же, есть компоненты!
Здравствуйте, hattab, Вы писали:
kuj>>2hattab: в .NET есть XML-RPC (и binary-RPC), к твоему сведенью, называется он WCF.
H>WCF это не оно
Чегой? WCF на SOAP это именно XML-RPC.
kuj>>.NET Framework действительно покрывает куда более широкий круг задач в отличии от VCL — в его составе есть даже реализации современных криптографических протоколов (блочный симметричный AES Rijndael, ассиметричный RSA, хеши MD5, SHAx и т.д. и т.д.).
H>VCL глупо сравнивать с FW, ибо VCL не есть фреймвок.
Конечно не есть. А другого у Delphi все-равно нет.
H>С шифрами все прикольнее... Ты в курсе, что криптография в Windows намеренно ослаблена? Какой в таком случае в них смысл...
Что значит ослаблена? Давай уж конкретнее и по пунктам.
kuj>>Другое дело, что фактически все внешние сборки во-первых: поставляются с исходниками и зачастую имеют хорошее покрытие unit-тестами (кстати, MS открыла исходные коды самого .NET Framework)
H>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
365MB в исходном кодах 210 библиотек? Что-то очень слабо верится.
kuj>>, во-вторых: имеют за плечами сотни и тысячи успешных проектов, что в целом значительно лучше, чем
H>Коли уж цифрами бросаешься, давай и ссылки.
Ссылки на что тебе давать?
kuj>>"создание самопального XML-RPC на Delphi, используя ручной подсчет ссылок для разруливания циклической зависимости, и где конфиги сами собой не пропадают, а если и пропадают, то система продолжает работать как и работала (c)hattab".
H>Не нужно мне приписывать свою интерпретацию моих слов Если решил цитировать, цитируй до буквы.
А что не так? Поправь, если я что не верно сказал.
kuj>>Кстати, так как я знаком с разработкой ПО для госконтор не по наслышке, уверяю, что там почти нету специалистов, которые бы имели представление о разработке ПО достаточное, чтоб запретить использование или неиспользование каких-то сторонних компонент/библиотек.
kuj>>Ну и наконец об "интерфейсах" в Delphi: интерфейсы в Delphi это костыль, который был добавлен исключительно для взаимодействия с COM и для создания .NET версии Delphi. Отсюда и требование наследоваться от IUnknown: вместо приведения типов еще на этапе компиляции в тех случаях, когда это возможно, всегда вызывается QueryInterface...
H>Иногда лучше жевать.
Аргументировать слабо?
H>kuj>Если в нормальных языках интерфейсы играют не менее значимую роль в ООП, чем классы, и являются мощным механизмом для обеспечения принципов инкапсуляции, то в Delphi использование интерфейсов носит скорее вынужденный характер и в основном в случаях, когда надо обеспечить COM-совместимость объекта.
kuj>>Поэтому и программирование в Delphi имеет вид скорее процедурного с элементами ООП, а не ООП с элементами процедурного (и функционального, кстати, что становится все более и более верно для .NET языков и платформы).
H>А этот бред даже комментировать не буду...
Здравствуйте, squid, Вы писали:
H>>Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
S>если дельфи не позиционировать сколько-нибудь широко она окончательно помрет.
Да она уже померла... Сейчас на стадии разложения.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, kuj, Вы писали:
kuj>>Да что говорить, SP1 для 3.5 тянет по перечню нововведений на 4.0: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
H>Да я только рад этому Опухнет в конец и лопнет раньше, чем доберется до моего HDD
H>Наличием исходников трудно кого то удивить... У меня в сборнике (очень скромном) Delphi сурсов, 210 бесплатных библиотек и юнитов общим весом в 365 мегабайт исходного кода.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, squid, Вы писали:
H>>>Меня убеждать не нужно. Ты сам попробуй понять ситуацию исходя из позиционирования продукта разработчиком.
S>>если дельфи не позиционировать сколько-нибудь широко она окончательно помрет.
kuj>Да она уже померла... Сейчас на стадии разложения.
ну, у меня проекту пару лет, не соскочишь уже...
Да и Delphi vs C++ для довольно простого невизуального unmanaged кода — для меня Delphi вполне разумный выбор. Был во всяком случае.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[28]: наши менеджеры памяти самые менеджеристые менеджеры
M>>Рассказываю. В гос. конторах любой сторонний компонент считается дополнительным послаблением безопасности. Все. Точка. Или всесторонний code review сторонних компонентов ты из своего кармана оплачивать будешь? Ну-ну, вперед.
H>Т.е. ты считаешь, что написание твоего велосипеда с последующим всесторонним тестированием, отладкой, доводкой, да еще в условиях изменяющихся требований будет стоить дешевле нежели ревью кода? Насмешил.
Все вопросы — к заказчику.
H>>>Хе-хе-хе. Следуя логике твоих слов, для тебя аналог MS Trident'а написать проще, чем юникод на VCL повесить (а ведь это можно сделать и без написания аналогов VCL контролам, al'a TNT) . Ню-ню.
M>>Как это следует из моих слов?
H>Очень просто: ты критикуешь необходимость самостоятельного написания поддержки Юникода в VCL, но при этом тебя не пугает перспектива написания движка аля Трайдент.
Кто говорит о необходимости переписывания Трайдента МС-овского? Он является стандартным компонентом системы. В отличие от.
M>>И что-то я не припомню стандартного легкого способа заставить VCL понимать и выводить текст на разных языках.
H>Можно обойтись класс-хелперами и перехватом API.
Какими-какими хелперами? Каким-каким перехватом?
Вот у меня есть список клиентов:
Tuğba Özay
Abdülhamîd Kılıçarslan
Сергей Иванов
Иван Сергеев
Хранятся они меня в базе данных. Для каждого имени рядом хранить еще и идентификатор языка, на котром они написаны? И так — для каждого текстового поля? А если мне надо их вывести одни списком? Чтобы рядом и Abdülhamîd и Иван оказались?
Наследуйся от TInterfacedObject и всех делов.
Ладно, кончай придуриваться. Согласись, что был не прав 
