kuj>>Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
H>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
Я говорю про production, которому уже 4 года. "Вот и все дела".
kuj>>>>>>В составе .NET FW нет реализации XML-RPC банально потому, что есть SOAP — более функциональный и удобный.
H>>>>>Очередной marketing-bullshit. Это ты расскажешь заказчику, у которого бизнес-процессы построены и на CORBA, и на SOAP, и на XML-RPC (большие системы имеют очень долгий цикл развития и целый зоопарк решений).
kuj>>>>http://www.xml-rpc.net/
H>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>Естественно, оно не нужно в составе Framework — его и нет.
H>
Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
kuj>>>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>>А парсить умеете без загрузки всего дока в память?
kuj>>>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>>>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
kuj>>RFTM про StreamReader, чтоли.
H>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
kuj>>>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>>Вполне реальная. Пусть даже с base64, какая разница.
kuj>>XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
H>XML-RPC с рождения умеет бинарные данные передавать без base64.
Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
H>>>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>>>И что?
H>>>Ты точно статью по ссылке читал?
H>>>>>С чего вдруг?
kuj>>>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>>>Вдумчиво перечитать
kuj>>Перечитал. При чем тут АНБ и какие-то там тенденции?
H>Мдя...
Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
Random Class
Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
Namespace: System
Assembly: mscorlib (in mscorlib.dll)
Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
kuj>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>Аргументируй.
H>>>Я для кого тут ссылки приводил?
kuj>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>Ппц... Про рандомные генераторы читал?
Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
H>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>Ссылки в студию.
H>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>Ясно. Значит пустозвонство.
H>Я тебе адрес дал. Интересно -- иди и читай.
google.com тебе противоречит. Интересно? Иди и читай.
kuj>>>>Это не имеет значения, если нет сверхмощностей, доступных только некоторым странам.
H>>>Да какие там сверхмощности... Ты статью читал??? Там ясно сказано, что ослабленные криптеры можно крошить чуть не на лету (и ведь, блин, авторы то из АНБ).
kuj>>Вот шифртекст. Не имея сверхмощностей, в приемлимые сроки дешифровать его ты не сможешь. Конец истории.
H>Т.е. не читал таки...
hattab тебе стоит почитать больше о криптографии.
kuj>>>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>>>Конечно не мешает, да только речь не о сторонних...
kuj>>>>Да ну, а о чем же речь?
H>>>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>>Генератор случайных чисел не является средством шифрования. Не знал?
H>Без него они не обходятся, не знал?
Алгоритмы шифрования в .NET FW не завязаны на конкретной реализации ГСЧ. Не знал?
kuj>>>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>>И для совместимости с COM. Разве это плохо?
kuj>>Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
H>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
H>В чем проблема наследования от TInterfacedObject? Религия?
legacy код.
kuj>>Интерфейсы в Делфи это жалкий костыль добавленный исключительно для работы с COM, а не как полноценная сущность ООП.
H>Весьма полноценная абстракция коей они и являются.
Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и даже представления не имеешь что такое настоящее ООП с применением таких техник как IoC/DI.
kuj>>>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>Просвяти, будь так добр.
H>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
Мда, значит очередное пустозвонство. Так и запишем.
kuj>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>Значит не знаешь?
H>>>Просто вопрос бредовый... ибо наследование.
kuj>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
Mamut пишет: > OCT>На Delphi тоже есть огромное количество отличных программистов. Правда, > OCT>со временем они имеют тендецию уходят на Аду или Оберон–2. > > Ну или на .NET
Если только на Зоннон. Иначе что может наш статистический олимпиадник
найти в .NET?
Я просто помню, как Delphi 8 в штыки встретили. Совсем не то, что от неё
ожидалось. Ну вообще не то. Тошнотворная
псевдообъектно–ориентированность. Совершенно извращённый взгляд на мир.
Классами называются всё, что ни попадя. Классы–утилиты, ну где это
видано? Классы–утилиты у нормальных людей называются модулями или
пакетами, финальные классы называются типами. Обычными типами, а не
классами. Не помню, чтоб кого–то в ту неделю пропёрло с этой дряни.
Здравствуйте, OCTAGRAM, Вы писали:
>> kuj>К тому же, есть полноценный XML-сериализатор. В отличии от... >> >> А парсить умеете без загрузки всего дока в память? Распарсишь гиговый >> XML на машинке с 512 Мб на борту? OCT>Сдаётся мне, в .NET для XML есть как DOM, так и SAX.
В том, что там есть SAX сомнений нет. Вопрос в другом: что используется по умолчанию в веб-сервисах (т.е. без ковыряния ручками).
Здравствуйте, Mamut, Вы писали:
M>>>Где ты в этой цитате нашел хоть слово про "миниязыки" — убей меня, не пойму.
H>>Протри окуляры. Там написано "мэни". Убейся сам.
M>Мэни — это не мини. Иди учи английский
У меня было написано "мэни". У МЕНЯ!!! Протри окуляры, уже.
M>>>Весь остальной бред про "идеологию" поскипан
H>>Вот и думаю, а мож послать вас?
M>Пошли, если бана не боишься
Здравствуйте, kuj, Вы писали:
kuj>>>Еще раз для тех кто в танке: вот веб-сервис на Java, вот клиент .NET — никаких проблем с маршалингом. Что я делаю не так?
H>>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
kuj>Я говорю про production, которому уже 4 года. "Вот и все дела".
Я тебе уже сказал, где ты можешь почитать о существующих несовместимостях. Чего ты мне своим продакшеном тычешь? Твои личные проекты это твое дело. Я сказал о существующих проблемах SOAP, как протокола, а ты мне "но у меня же работает"...
H>>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>>Естественно, оно не нужно в составе Framework — его и нет.
H>>
kuj>Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
Если оно действительно ненужно, зачем тогда сторонние тулы? MS'у понятное дело ничего кроме своего ненужно...
kuj>>>>>>>К тому же, есть полноценный XML-сериализатор. В отличии от...
H>>>>>>А парсить умеете без загрузки всего дока в память?
kuj>>>>>Конечно умеет. StreamReader -> TextReader -> XmlSerializer
H>>>>А веб-сервис парсит пакет по мере поступления или сперва полностью получит, а затем парсит?
kuj>>>RFTM про StreamReader, чтоли.
H>>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
kuj>При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
Вместо нескольких предложений с объяснением, легче сказать RTFM. Вот и я тебе скажу RTFM или в исходники пошлю. Мысль понятна?
kuj>>>>>Это нереальная ситуация. Если у тебя XML растет до 1 GB и это не из-за base64 вставок, то пора править руки программистам.
H>>>>Вполне реальная. Пусть даже с base64, какая разница.
kuj>>>XML-RPC, поди? SOAP давно умеет бинарные данные передавать отдельно — бинарным потоком не кодируя в base64.
H>>XML-RPC с рождения умеет бинарные данные передавать без base64.
kuj>Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?
Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.
Экранируем требуемое и все.
H>>>>>>Над безопасностью в Висте МС работала с АНБ.
kuj>>>>>И что?
H>>>>Ты точно статью по ссылке читал?
H>>>>>>С чего вдруг?
kuj>>>>>Американская компания работает с американской службой. С чего вдруг? Сложный вопрос, что ни говори...
H>>>>Вдумчиво перечитать
kuj>>>Перечитал. При чем тут АНБ и какие-то там тенденции?
H>>Мдя...
kuj>Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
kuj>
kuj>Random Class
kuj>Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
kuj>Namespace: System
kuj>Assembly: mscorlib (in mscorlib.dll)
kuj>Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
kuj>Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
Ладно. Не напрягайся. Я вижу, что ты ничего не хочешь видеть и веришь всему что тебе преподносит МС. Крепкого сна.
kuj>>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>>Аргументируй.
H>>>>Я для кого тут ссылки приводил?
kuj>>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>>Ппц... Про рандомные генераторы читал?
kuj>Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
Да что ты пристал к этому AES??? Криптография AES'ом не ограничивается. Я же тебе сразу сказал о тенденциях...
H>>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>>Ссылки в студию.
H>>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>>Ясно. Значит пустозвонство.
H>>Я тебе адрес дал. Интересно -- иди и читай.
kuj>google.com тебе противоречит. Интересно? Иди и читай.
Я тебе вполне конкретный сайт указал, там найдешь руководство пользователя и вперед.
kuj>>>>>>>Что, тем не менее, не мешает использовать другую реализацию генератора случайных чисел тогда, когда это требуется.
H>>>>>>Конечно не мешает, да только речь не о сторонних...
kuj>>>>>Да ну, а о чем же речь?
H>>>>Ты начал рассказывать о имеющихся в FW средствах шифрования. Забыл?
kuj>>>Генератор случайных чисел не является средством шифрования. Не знал?
H>>Без него они не обходятся, не знал?
kuj>Алгоритмы шифрования в .NET FW не завязаны на конкретной реализации ГСЧ. Не знал?
И сколько раз мне повторить, что обсуждаются тут встроенные средства, а не сторонние?
kuj>>>>>Совершенно верно. Для совместимости с COM. Наконец до тебя дошло.
H>>>>И для совместимости с COM. Разве это плохо?
kuj>>>Плохо то, как их реализовали — ОЧЕНЬ плохо, что не возможен кастинг объектов к любому из предков интерфейса. Плохо то, что надо либо наследоваться от TInterfacedObject, либо реализовывать AddRef, Release, QueryInterface — плохо, т.к. оверхид и лишняя работа.
H>>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
kuj>Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
Я проблемы понять не могу... Сложно вместо MyInterface написать IInterface, MyInterface? Причем только в том классе, которые его действительно реализует, потомки также будут его реализовать, но декларировать это от них не требуется.
H>>В чем проблема наследования от TInterfacedObject? Религия?
kuj>legacy код.
Какое еще наследие? Ты что? Этот TInterfacedObject существует с 3 версии...
kuj>>>>>Класс, наследующий интерфейс, обязан этот интерфейс реализовать. Если ты ломаешь идеологию, возвращая в QueryInterface ссылки на внешние объекты, то это характеризует платформу как абсолютно бредовую.
H>>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>>Просвяти, будь так добр.
H>>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
kuj>Мда, значит очередное пустозвонство. Так и запишем.
Твоя картина мира снова дала трещину? Сочувствую.
kuj>>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>>Значит не знаешь?
H>>>>Просто вопрос бредовый... ибо наследование.
kuj>>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
kuj>Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
Я тебе повторю, что если ты получишь интерфейс из внешнего источника, куда .net со своей рефлексией не доползет, то уж придется таки дергать QueryInterface. Впрочем, если для тебя весь мир это .Net... Сочувствую.
Здравствуйте, abibok, Вы писали:
OCT>>"Отличные" можно понимать по–разному. На Паскале много олимпиадников OCT>>выросло. В школьные годы все, как один, писали олимпиады на этом языке.
OCT>>Вот только не знаю, сколько из них [олимпиадников] вообще сидят на OCT>>форумах, в том числе RSDN.
A>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
У меня первое место по республике среди выпусных классов.
Здравствуйте, hattab, Вы писали:
H>>>У тебя работает и ты спокоен. У твоего заказчика перестанет и станешь в неудобную позу. Вот и все дела.
kuj>>Я говорю про production, которому уже 4 года. "Вот и все дела".
H>Я тебе уже сказал, где ты можешь почитать о существующих несовместимостях. Чего ты мне своим продакшеном тычешь? Твои личные проекты это твое дело. Я сказал о существующих проблемах SOAP, как протокола, а ты мне "но у меня же работает"...
Называется слышал звон, да не знаю где он. hattab ты смешон.
H>>>>>А кто-то говорил, что оно и нафиг не нужно ибо есть SOAP
kuj>>>>Естественно, оно не нужно в составе Framework — его и нет.
H>>>
kuj>>Что тебя так насмешило? Расскажи я тоже хочу посмеяться.
H>Если оно действительно ненужно, зачем тогда сторонние тулы? MS'у понятное дело ничего кроме своего ненужно...
Оно не нужно в составе Framework. Что тебе еще не понятно?
H>>>В следующий раз я тебя к исходникам VCL отправлю, ты не удивляйся.
kuj>>При чем тут исходники? hattab, Delphi оказывает паршивое влияние на мыслительные процессы.
H>Вместо нескольких предложений с объяснением, легче сказать RTFM. Вот и я тебе скажу RTFM или в исходники пошлю. Мысль понятна?
Я тебе дал название конкретного класса, документация по которому находится за минуту на MSDN. Или тебе все надо разжевать и в рот положить?
H>>>XML-RPC с рождения умеет бинарные данные передавать без base64.
kuj>>Да ну, серьезно? Ну-ка, ну-ка, ссылку на место в спецификации, где описано как XML-RPC передает бинарные данные без кодирования их в один из текстовых форматов.
H>
H>What characters are allowed in strings? Non-printable characters? Null characters? Can a "string" be used to hold an arbitrary chunk of binary data?
H>Any characters are allowed in a string except < and &, which are encoded as < and &. A string can be used to encode binary data.
Те же яйца только в профиль — кодирование в любом случае потребуется. SOAP же умеет передавать бинарные данные как есть в виде аттача — без оверхида и без конвертации.
Добро пожаловать в 2008ой год хаттаб.
H>>>Мдя...
kuj>>Ты сам хоть понимаешь какую чушь несешь? По твоей ссылке лишь сказано, что в какой-то старой версии Windows был криво реализованный генератор случайных чисел, цепочки которого можно с помощью специальной атаки предугадывать наперед, имея доступ к компьютеру. Потом было сказано, что они не знают точно справедливо ли это для Windows XP и уж тем более ничего не сказано о Vista, АНБ, реализации генератора в .NET (исходники которой открыты, FYI) и каких-то там тенденциях.
kuj>>
kuj>>Random Class
kuj>>Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
kuj>>Namespace: System
kuj>>Assembly: mscorlib (in mscorlib.dll)
kuj>>Pseudo-random numbers are chosen with equal probability from a finite set of numbers. The chosen numbers are not completely random because a definite mathematical algorithm is used to select them, but they are sufficiently random for practical purposes. The current implementation of the Random class is based on Donald E. Knuth's subtractive random number generator algorithm. For more information, see D. E. Knuth. "The Art of Computer Programming, volume 2: Seminumerical Algorithms". Addision-Wesley, Reading, MA, second edition, 1981."
kuj>>Если у тебя есть сомнения по поводу .NET реализации генератора случайных чисел рисуешь трехмерную систему координат и куб со стороной 1, заполняешь этот куб точками, координаты которых получены с помощью данного генератора. Любую существенную неравномерность распределения можно будет увидеть на глаз, если таковая имеет место быть.
H>Ладно. Не напрягайся. Я вижу, что ты ничего не хочешь видеть и веришь всему что тебе преподносит МС. Крепкого сна.
Значит по существу сказать нечего. Ясно. Слив засчитан.
kuj>>>>>>>>Еще раз повторяю DES уж много лет как не применяется в свете наличия гораздо лучших шифров, как например Rijndael.
H>>>>>>>Да хоть каким современным будь здание, но если у него фундамент гнилой...
kuj>>>>>>Аргументируй.
H>>>>>Я для кого тут ссылки приводил?
kuj>>>>В чем "гнилость фундамента" шифра Rijndael? Давай по пунктам.
H>>>Ппц... Про рандомные генераторы читал?
kuj>>Какое они имеют отношение к шифру Rijndael? Представь себе, я могу подставить любую реализацию ГСЧ.
H>Да что ты пристал к этому AES??? Криптография AES'ом не ограничивается. Я же тебе сразу сказал о тенденциях...
Ты сказал, что у Rijndael гнилой фундамент я попросил аргументировать, ты дал ссылку на желтопрессную статейку о том, что стандартный ГСЧ в старых версиях Windows имел проблемы. Так вот в .NET FW класс Random реализует алгоритм, описанный Кнутом в 1981 году и его исходники общедоступны. Все еще не дошло? мда... Делфи реально отупляет.
H>>>>>>>Кстати, Rijndael не был лучшим по результам тестов на потенциальные уязвимости см. руководство TrueCrypt (там есть ссылочки на первоисточники).
kuj>>>>>>Ссылки в студию.
H>>>>>Иди на TrueCrypt.org и читай. Мне не хочется из PDF'а ссылки выцарапывать.
kuj>>>>Ясно. Значит пустозвонство.
H>>>Я тебе адрес дал. Интересно -- иди и читай.
kuj>>google.com тебе противоречит. Интересно? Иди и читай.
H>Я тебе вполне конкретный сайт указал, там найдешь руководство пользователя и вперед.
Слив засчитан.
H>>>Кастить можно к любому заявленному реализованным предку интерфейса. Написано об этом раз десять уже.
kuj>>Какой смысл в наследовании интерфейсов, в таком случае? Ведь все-равно, чтоб обратиться к методам и свойствам предка придется явно указывать, что класс реализует конкретно этого предка.
H>Я проблемы понять не могу... Сложно вместо MyInterface написать IInterface, MyInterface?
Во-первых, сложно. Во-вторых, это банально бред перечислять предков. Что если интерфейс в пятом поколении, а класс должен реализовать 4 подобных интерфейса?
H>>>В чем проблема наследования от TInterfacedObject? Религия?
kuj>>legacy код.
H>Какое еще наследие? Ты что? Этот TInterfacedObject существует с 3 версии...
Мда, ты не знаешь что такое legacy код? Смешно.
H>>>>>Никаких внешних объектов нет. Я вижу, что нападающие тут ты не сильно изобретательны (один про хэлперы не въезжает, другой мыслит шаблонно...)
kuj>>>>Просвяти, будь так добр.
H>>>Ну вот, я говорил про исходиники VCL... Ознакомься с RIO.pas
kuj>>Мда, значит очередное пустозвонство. Так и запишем.
H>Твоя картина мира снова дала трещину? Сочувствую.
Слив засчитан.
kuj>>>>>>>>Почему можно скастить объект к абстрактному предку без всяких QueryInterface`ов?
kuj>>>>>>Значит не знаешь?
H>>>>>Просто вопрос бредовый... ибо наследование.
kuj>>>>Наследование это сферический конь в банаховом пространстве. Почему в случае наследования не нужен QueryInterface?
H>>>На момент компиляции все известно, чего там запрашивать? Ты попробуй обойтись без QueryInterface при работе с интерфейсом полученныйм от внешнего источника в виде базового IUnknown.
kuj>>Представь себе за "базовым IUnknown" всегда лежит конкретный объект, который его реализует. Продолжать?..
H>Я тебе повторю, что если ты получишь интерфейс из внешнего источника, куда .net со своей рефлексией не доползет,
.NET прекрасно взаимодействует с COM-объектами и без бредового перечисления предков вплоть до IUnknown. Не знал?
H>то уж придется таки дергать QueryInterface. Впрочем, если для тебя весь мир это .Net... Сочувствую.
kuj пишет: > Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и > даже представления не имеешь что такое настоящее ООП с применением таких > техник как IoC/DI.
А что в DI такого особенного, что это преподносится как существенный
плюс? С тем же успехом существенным плюсом можно назвать mix-in.
Почему DI?
Здравствуйте, hattab, Вы писали:
A>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>У меня первое место по республике среди выпусных классов.
Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
>> Продолжай повторять себе это. Ты зациклен в своем ограниченном мирке и >> даже представления не имеешь что такое настоящее ООП с применением таких >> техник как IoC/DI.
OCT>А что в DI такого особенного, что это преподносится как существенный OCT>плюс? С тем же успехом существенным плюсом можно назвать mix-in. OCT>Почему DI?
Потому что IoC/DI позволяет сделать 100% decoupling реализаций.
Здравствуйте, _d_m_, Вы писали:
A>>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>>У меня первое место по республике среди выпусных классов.
___>Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
Свои откровения можешь оставить при себе... "Не судить... Жить по совести..." трепло
Здравствуйте, OCTAGRAM, Вы писали:
>> Потому что IoC/DI позволяет сделать 100% decoupling реализаций.
OCT>13 лет уже как позволяет, сейчас–то чего вдруг вспомнили?
Вспомнили в контексте разговора. Существующая реализация Делфи не позволяет создать полноценный IoC-контейнер.
Здравствуйте, hattab, Вы писали:
A>>>>Ну я был олимпиадником. Областные — на GW-BASIC, республиканские — на Turbo Pascal. На первых курсах университета писал на Delphi и С++ Builder. Потом полностью перешел на С++, а сейчас — на C#.
H>>>У меня первое место по республике среди выпусных классов.
___>>Наверное, это было настолько сильное впечатление для тебя, что тебя просто заклинило на Delphi
H>Свои откровения можешь оставить при себе... "Не судить... Жить по совести..." трепло
Если такие кадры как ты побеждают на олимпиадах, то я начинаю откровенно сомневаться в уровне заданий на этих "олимпиадах". Чего только стоит твои гениальные алгоритмы, где парент и чайлд зависят друг от друга и должны в определенном порядке во время дестракшина производить еще какие-то вычисления... /моя плакать...
Про качество кода, писанного тобой я лучше вообще промолчу...
kuj пишет: > Вспомнили в контексте разговора. Существующая реализация Делфи не > позволяет создать полноценный IoC-контейнер.
Вот mix-in Delphi точно не позволяет сделать. А DI?
Constructor Injection, Setter Injection, Interface Injection — это всё
возможно в Delphi. Классы можно по их имени создавать, свойства можно по
их имени присваивать. Я потерял нить (к слову о том, как хорошо менять
тему), где начинается "нельзя"?
H>>>Протри окуляры. Там написано "мэни". Убейся сам.
M>>Мэни — это не мини. Иди учи английский
H>У меня было написано "мэни". У МЕНЯ!!! Протри окуляры, уже.
Аааа... Ну тогда учти, Дельфи входит в разряд этих многих языков.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>kuj пишет: >> Вспомнили в контексте разговора. Существующая реализация Делфи не >> позволяет создать полноценный IoC-контейнер. OCT>Вот mix-in Delphi точно не позволяет сделать. А DI?
OCT>Constructor Injection, Setter Injection, Interface Injection — это всё OCT>возможно в Delphi. Классы можно по их имени создавать, свойства можно по OCT>их имени присваивать. Я потерял нить (к слову о том, как хорошо менять OCT>тему), где начинается "нельзя"?
1. Отсутствие generic`ов.
2. Отсутствие полноценной иерархии интерфейсов.
3. Невозможность реализации механизма interception, на котором базируется AoP.
продолжать?
Или лучше задай себе вопрос — почему за столько лет в Delphi не появилось ни одного IoC/DI-контейнера, тогда как в Java и .NET их очень много (счет идет на десятки)?
Здравствуйте, kuj, Вы писали:
kuj>Если такие кадры как ты побеждают на олимпиадах, то я начинаю откровенно сомневаться в уровне заданий на этих "олимпиадах". Чего только стоит твои гениальные алгоритмы, где парент и чайлд зависят друг от друга и должны в определенном порядке во время дестракшина производить еще какие-то вычисления... /моя плакать...
Это нормально. Подумай что такое вообще олимпиады про программированию: человек решает абстрактную (!) вычислительную (!) задачу в очень ограниченное время (!) с жесткими требованиями по быстродействию (!) (хотя иногда без таких требований).
При таких исходных данных никакой архитектурой и не пахнет.
У тех кто часто участвует в таких олимпиадах появляется привычка писать код "быстро" и "оптимально". О качестве такого кода промолчу.
