Здравствуйте, Ведмедь, Вы писали:
H>>>>Давай не будем углубляться в эту тему. В вопросе о цене владения перевес будет явно не на стороне .Net (но мне эту тему развивать не сильно интересно)
В>>>Конечно не на стороне .NET, цена владениа у Delphi окажется выше.
H>>Бла-бла-бла. Наслушался уже. Завязывай.
В>Прекрасный аргумент! браво!
Я тоже самое сказал о твоем аргументе. Ты разницу видишь? Я нет.
Здравствуйте, Ведмедь, Вы писали:
В>>>Ээээ ты просто не в курсе, действительно не обязывают. Как хранить и использовать это секцальное дело программиста, может использовать конфиги стандартные, может свой велосипед изобрести, может для каждого компа в коде все прошить.
H>>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
В>Тот который удобней ему или тот который ему навяжет архитектор системы. В>Ты знаешь у нас КТС системы более 50-ти серверов, на каждом сервере более десятка источников конфигурации. И проблемы с конфигураций возникают только при глобальной смене функциональности... Ну не трогают адмимны то что работает, отучены совать свои ручки.
Ты знаешь, у Януса есть конфиг, который пользователся нужно править руками. И? Это что-то показало в целом? Не показало. Можно сделать хорошо, а можно по указателю проследовать и получить геморой. Теперь ясно?
В>А какой подход использует дельфи к конфигурации? Реестр? Писать в коде? Есть ли у дельфи идеология конфигурирования? Аналоги application block от МС?
Какой больше нравится тот и используй. Хочешь реестр, используй реестр. Нравятся ini'шки — бога ради. Нужен XML, тоже не вопрос... Я тут, вообще говоря, проблемы совсем ни какой не вижу.
Здравствуйте, Ведмедь, Вы писали:
В>>>То надо трахать техподдержку. Разработчик тут не причем. Или ты вообще конфигами не пользуешься? Что для под каждый комп свою версию компилируешь?
H>>.Net — разработчик, как я уже понял, всегда ни при чем: за него все решили, за него все написали, ему показали дорогу в светлое будущее
В>Ага... а если кто то в дельфи удалит испольняемый файлы все будет работать нормально? Или покорежит конфиги? Или адреса для удаленным обращениям прошиваются в коде? Или виноват будет разработчик? Конфиги так же являются частью системы и за конфигураций отвечает тех поддержка.... И только в случае полных непоняток тех поддержка начнет дергать разработка...Или по твоему разработчик должен по первому крику заказчика мчаться на площадку и там быстро все переписывать?
Знаешь, как бывает в жизни... У начальника отдела кадров, вдруг (практикант удалил шаблоны документов), перестали открываться анкетки сотрудников. Начальник ОК не звонит в тех.поддержку, не звонит разработчику, а звонит начальнику ИТ для высказывания своего фи в неличеприятной форме. Вопрос: кого после этого вы#бут (будь уверен, не практиканта)?
Здравствуйте, Ведмедь, Вы писали:
В>>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?
H>>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
В>И ты в резюме бы так же написал "много чего до паскаля, после него Ада в ознакомительном режиме"? В>Оссобенно инетересно какими языками ты зарабатывал на жизнь программированием? Или "много чего " было в школе, а потом только delphi?
Я к тебу на работу не нанимаюсь
В>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
В>Время запуска GC конечно не детерминировано? Очень не понятно что значит в нейтиве не освободиться? После того как пройдет сборка мусора освободятся все занятые ресурсы. А у нейтива посыл другой все что взял, то и верни... меньше вернул — лики и потери ресурсов, больше вернул — аксесвиолейщн. Управляемый код защищает от второго, уменьшает первую проблему.
Здравствуйте, Mr.Cat, Вы писали:
MC>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция:
Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Здравствуйте, gandjustas, Вы писали:
H>>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то? G>Какая проблема? G>У программы на Java\.NET конфиги пропадают чаще, чем у программы на делфи?
Уже описал десять раз и вижу, что ты не понимаешь. Либо перечитывай до просветления, либо давай завязывать, ибо ничего нового я тебе не напишу.
Здравствуйте, hattab, Вы писали:
В>>Тот который удобней ему или тот который ему навяжет архитектор системы. В>>Ты знаешь у нас КТС системы более 50-ти серверов, на каждом сервере более десятка источников конфигурации. И проблемы с конфигураций возникают только при глобальной смене функциональности... Ну не трогают адмимны то что работает, отучены совать свои ручки.
H>Ты знаешь, у Януса есть конфиг, который пользователся нужно править руками. И? Это что-то показало в целом? Не показало. Можно сделать хорошо, а можно по указателю проследовать и получить геморой. Теперь ясно?
То есть ты все .NET программы равняешь под одну гребенко по кривому янусу? Помню Delphi программу, которая при запуске падала с Access Violation! Вывод — Delphi отстой! программы на Delphi работать не будут.
Здравствуйте, hattab, Вы писали:
MC>>В .NET ресурсы, для которых важна детерминированность времени освобождения (файлы, соединения) оборачиваются в объекты, реализующие интерфейс IDisposable (это даже можно считать паттерном). По команде Dispose() объект сразу освобождает ресурс, после чего переходит в состояние Disposed ("я ресурсом уже не владею") и спокойно себе дожидается, пока его соберет GC и освободит все оставшиеся ресурсы (память, в частности). В С# (за VB не скажу) есть даже специальная конструкция:
H>Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Если ты не понимаешь разницы между памятью и другими ресурсами системы, то это лишь квалифицирует тебя как непрофессионала.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>.Net на десктопе, это Paint.NET наверное . Native Rich Desktop Application это и есть основной сегмент для Delphi.
А примеры можно?
H>А что такое Web-разработка? Можешь, впрочем, не отвечать, ибо люди даже о термине Web 2.0 договориться не могут, а уж мы тут (с куда более общим понятием) точно взаимопонимания не найдем.
Договориться не могут, потому что Web 2.0 — маркетинговый термин, а не технический. http://en.wikipedia.org/wiki/World_Wide_Web — начинай определяться
Здравствуйте, hattab, Вы писали:
M>>Какую? Азы наследования? Так \это не мне их нао изучать
H>Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
IUnknown != INonCOMInterface, но INonCOMInterface == IUnknown, так как является непосредственным наследником.
INonCOMInterface можно скастить к IUnknown. Учи матчасть, нуб.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ведмедь, Вы писали:
H>Знаешь, как бывает в жизни... У начальника отдела кадров, вдруг (практикант удалил шаблоны документов), перестали открываться анкетки сотрудников. Начальник ОК не звонит в тех.поддержку, не звонит разработчику, а звонит начальнику ИТ для высказывания своего фи в неличеприятной форме. Вопрос: кого после этого вы#бут (будь уверен, не практиканта)?
Тебя наверное. Сколько работал — таким всегда техподдержка занималась.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Mamut, Вы писали:
M>>Теперь осталось понять, что тебе не понравилось в примере Синклера
kuj>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>>>>Тот факт, то второй интерфейс не совместим с типами COM означает обычно только то, что у программиста руки кривые.
H>>> Учи матчасть.
M>>Какую? Азы наследования? Так \это не мне их нао изучать
H>Наследование тут ни при чем. IUnknown и INonCOMInterface это разные интерфейсы. Еще раз говорю, учи матчасть.
Может, все же почитаешь про наследование, а?
INonCOMInterface наследуется от IUnknown. Более того (или, вернее, поэтому), INonCOMInterface может быть приведено к IUnknown. Более того, наследование от IUnknown означает, что для INonCOMInterface автоматически становятся доступны три базовых COM-метода: AddRef, Release и QueryInterface (потому что они реализованы в IUnknown)
Здравствуйте, Mamut, Вы писали:
M>>>Теперь осталось понять, что тебе не понравилось в примере Синклера
kuj>>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>К какой из них?
Здравствуйте, hattab, Вы писали: H>Все верно Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом
Не совсем так. Если программисту не важно, когда будет закрыт(о) файл/соединение — он ничего не делает (при этом файлы и соединения будут закрываться в процессе финализации). Если ему это Важно — у него есть IDisposable. Вот и всё. Единственный источник возможных проблем — файл/соединение должно грамотно реализовывать этот IDisposable. Т.е. программист в этом вопросе не застрахован от чужих (ну или своих, если он сам разрабатывает disposable-объект) кривых рук. Впрочем, в MSDN есть пример корректной реализации.
Здравствуйте, hattab, Вы писали:
___>>Спорить в разрезе Дельфи-ДотНет и приводить в качестве аргумента какие-то пропадающие конфиги — это либо — в споре все средства хороши, либо проблемы с неадекватным восприятием реальности.
H>Никто в таком разрезе не спорит. Я уже пояснял, кажется. Ну а конфиги... Ну ведь есть прблема, чего ее отрицать-то?
Какая проблема? Что отрицать? Что у кого-то там пропали конфиги по вине юзеров и что это проблема ДотНет, а мол дельфины и без конфигов работают — ну это ахинея.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
___>>>>"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
H>>>А судьи кто?
___>>Попробую объяснить на аналогии. Вот есть, к примеру, автомобиль ВАЗ и есть аналогичный ему Toyota Corolla. Так вот, один из них ведро с гайками, однозначно. Ответь на вопрос: а судьи кто?
H>Аналогии не катят. Ибо ты не пробовал проектировать Абрамс и ИС немецкой ЖД.
Жаль, что для тебя не катят. Но я проектировал многое другое, и знаком с другими проектами и эти проекты мне приходилось/приходится обслуживать. Плюс, есть опыт эксплуатации этих продуктов многими другими людьми. А теперь подумай про автомобили — аналогии катят.
skip G>А зачем знать? достаточно чтобы объект был сериализуемым (имел соответсвующий атрибут).
А смысл просто передачи объекта класса в метод, если его десериализовать в методе не получиться? G>В COM нельзя любой класс передать в метод.
Что в *.idl, по-моему там, опишешь, то и передашь
kuj>>>Мне все понравилось кроме того, что его пример не имеет никакого отношения к теме спора.
M>>К какой из них?
kuj>К той, о которой ты не имеешь представления.
Ню-ню. Про ГУИ, судя по всему, ты тоже не имеешь представления
Я говорил о другом. Cначала тебе говорят: Расслабься, ничего убирать не нужно, все само уберется. А потом говорят: Ну нифига ты расслабился, а ресурсы, кто за тобой убирать будет? Я только об этом 
или не судьба грамотно обрабатывать ситуацию их отсутствия 
