Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
Щас тебя закидуют тухлыми помидорами, потому что в делфи, кажись с пятой версии, есть ADO. Причем именно ADO является основным иструментом с тех пор.
Здравствуйте, gandjustas, Вы писали:
H>>>>>>Что, ссылки руками считаете, или наоборот нет возможности ручного управления? G>>>>>.NET ссылки считает. H>>>>Т.е. ручками вам не дают считать? G>>>Не дают. H>> Я и не удивлен даже, после претензий высказываемых в адресс Delphi. G>Чего смешного. Назови 3 объективные причины вызывать AddRef и Release. G>Только не забывай, что в делфи это еще сопровождается автоматическй считалкой, что очень чревато багами при совмещении того и другого.
Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
H>>Ни каких чисток делать не нужно, ибо это интерфейс диспетчеризации лежащий в вариантной переменной (сразу скажу, что то же самое можно делать и через объектные заглушки, и через advanced records заглушки), для которых работает управляемая сборка мусора. Фризов там просто не может быть т.к. эта сборка ни чем не отличается от ручной очистки сырой памяти (кроме автоматизации сего процесса), которая не накапливается в поколениях. G>И в какой момент эта сборка мусора происходит?
В момент выхода переменых из области видимости. Ты не знал?
H>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>И есть exeшники по 1.5 метров. Спасибо, поржал.
В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю
G>В .NET и Java компонентный подход гораздо сильнее, чем в делфи. Причем он гораздо более умно сделан. Нету привязки всего к формам.
У нас привязки к формам тоже нет Это очередная нелепая нападка.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Недостатки: отсутствие толковой оптимизации кода, что делает его медленнее Явы и Шарпа. Отвратительно уродский слой работы с базами данных под названием BDE. Проблемы с обращением к компонентам OLE Automation.
Оптимизация кода не идеальная. Но этот код не медленнее Java/C# (для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi). Примеры приводить не буду, пенисометрия мне не интересна. Если угодно, пусть это останется моим голословным утверждением по аналогии с уже звучавшими от опонентов. BDE это конечно кошмар, но уже давно есть и ADO, и DbExpress (который, к слову, и является основной рекомендуемой техникой). Проблем с OLE Automation не испытываю со времен пятерки.
MSS>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE.
Object-based лучше Object-Oriented (Или VB6 уже был полноценным OO-language?)
Здравствуйте, hattab, Вы писали:
H>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом.
Здравствуйте, Эдик, Вы писали:
Э>Здравствуйте, hattab, Вы писали:
H>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Э>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом.
Ну расскажи, как автоматом разрулятся взаимные ссылки
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>VB6 был намного лучше, ибо свободен от этих проблем (у него полноценный компилятор, вторая фаза от MS C++ compiler). У него ADO вместо BDE. G>Щас тебя закидуют тухлыми помидорами, потому что в делфи, кажись с пятой версии, есть ADO. Причем именно ADO является основным иструментом с тех пор.
ADO, DbExpress (основная) и целая куча нативных движков начиная от Oracle и заканчивая самыми примитивными. У тебя, как всегда, информация из 98-2000 Хватит уже лаять в след давно ушедшему поезду.
Здравствуйте, hattab, Вы писали:
H>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок.
Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM.
Короче причин не вижу, слив засчитан.
H>В момент выхода переменых из области видимости. Ты не знал?
А если объект сохраняется в глобаьной переменной или поле класса, то когда?
H>>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>>И есть exeшники по 1.5 метров. Спасибо, поржал.
H>В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю
Это к вопросу о маленьком ядре и компонентах.
Здравствуйте, kuj, Вы писали:
WH>>Ибо ерланг и пролог имеют очень разные вычислительные модели. kuj>Не на столько разные, чтоб заморачиваться.
После этого заявления все твои суждения о языках программирования можно отправлять в топку вобще не читая.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Эх, Мамут-Мамут, сам-то читал? Эрланг и Пролог — функциональные языки.
Ага. И форт с паскалем тоже.
kuj>Эрланг базируется на идентичном Прологу синтаксисе. Да, в Эрланг много всего того, чего нет в Прологе, но это не значит, что он хуже для преподавания. Скорее наоборот. Эта вакансия
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Эдик, Вы писали:
Э>>Здравствуйте, hattab, Вы писали:
H>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>Ну расскажи, как автоматом разрулятся взаимные ссылки
Здравствуйте, WolfHound, Вы писали:
kuj>>IoC контейнер это больше, чем классическая фабрика. WH>И что в нем такого?
Например, декларативное управление зависимостями.
Хотя под шаблон "фабрика" вообще многое можно подогнать...
Здравствуйте, gandjustas, Вы писали:
H>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. G>Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM. G>Короче причин не вижу, слив засчитан.
Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
H>>В момент выхода переменых из области видимости. Ты не знал? G>А если объект сохраняется в глобаьной переменной или поле класса, то когда?
В глобальной переменной будет храниться до тех пор, пока ей не будет назначено другое значение. В поле класса аналогично, или до тех пор, пока объект-владелей жив.
H>>>>У Delphi никогда и небыло амбиций всереализующей платформы. Ее идеология в другом: есть очень немаленькое ядро, и есть компонентный подход. G>>>И есть exeшники по 1.5 метров. Спасибо, поржал.
H>>В MS Office есть экзешки по 3 метра, и? Размер файла вообще придирка странная: ни на чем негативно не сказывается, избавиться от этого элементарно (у нас есть пакеты). Проблема из области психологии, полагаю G>Это к вопросу о маленьком ядре и компонентах.
Читай внимательно: "немаленькое ядро". Немаленькое не в смысле размера, а в смысле охватывата.
Здравствуйте, gandjustas, Вы писали:
H>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>Не боись, действительно все это разруливается.
Очень хочется послушать, как это будет сделано. Жду.
Здравствуйте, Cyberax, Вы писали:
C>Например, декларативное управление зависимостями. C>Хотя под шаблон "фабрика" вообще многое можно подогнать...
И я о томже.
Тем болие в контексте разговора нам по любому нужно зависить от чегото.
А как это что-то назвать фабрика, IoC контейнер, хрумбабулек прумкабятый,... не важно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
(с примерами реализации). Идея в том, чтобы отделить граф "доступных" объектов от графа "недоступных", несмотря на наличие взаимных ссылок у "недоступных" объектов.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. Э>>>>Вот здесь и проявятся плюсы .NET — на Delphi (да и на любой другой платформе без GC) надо писать все эти AddRef, Release (не факт, что не забудешь вызвать их в нужном месте), а на .Net, Java etc. все происходит автоматом. H>>>Ну расскажи, как автоматом разрулятся взаимные ссылки
G>>Не боись, действительно все это разруливается.
H>Очень хочется послушать, как это будет сделано. Жду.
Если дочерний объект ссылается на родителя, то он увеличивает ему счетчик сылок. Тогда родительский объект будет жить пока живут дочерние. Соответственно если объект создает дочерние, то он и должен их удалять. Это вообще COM-объект так должен работать.
.NET объекты выставленные как COM так и работают
Здравствуйте, WolfHound, Вы писали:
WH>Тем болие в контексте разговора нам по любому нужно зависить от чегото. WH>А как это что-то назвать фабрика, IoC контейнер, хрумбабулек прумкабятый,... не важно.
Вот ClassA, который зависит от IInterfaceB. Вот ClassB : IInterfaceB. В ClassA нет ни одного упоминания ни ClassB, ни IoC-контейнера.
IoC.Resolve<> с помощью DI конструирует и передает объекты ClassB в ClassA (setter / interface / constructor injection). Более того, IoC-контейнеры часто используются для AoP (aspect oriented programming) с помощью interceptors и dependency injection.
H>>>Дано: Интерфейс (именно интерфейс) родитель имеющий список дочерних элементов, так же интерфейсов (это обязательно). Работоспособность дочерних элементов зависит от жизни родителя (т.е. родитель не может умереть пока жив хоть один дочерний элемент). Соответственно дочерние элементы имеют ссылку на интерфейс-родитель. Тут возникает проблема: имеем перекрестные (взаимные) ссылки. Решение должно учитывать тот факт, что пользователь родительского объекта не знает о его заморочках и будет использовать стандартную практику работы с интерфейсными переменными. Предлагай решение без подсчета ссылок. G>>Такое в .NET работает нормально. .NET не отменяет подсчет ссылок (это вообще обязанность COM объекта), .NET скрывает это от программиста. Поэтому в .NET нету разницы между COM и не-COM. G>>Короче причин не вижу, слив засчитан.
H>Ты давай расскажи, как .Net будет разруливать это. Мне ждать ответа, или ты слил?
Я и не удивлен даже, после претензий высказываемых в адресс Delphi.
Это очередная нелепая нападка.
