Здравствуйте, hattab, Вы писали:


H>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
Можешь не спорить, это факт.

Здравствуйте, gandjustas, Вы писали:

H>>>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
WH>>>Хватит решение расказывать.

H>>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.

G>Тебе уже 3 человека написали чтобы ты сказал исходное условие задачи.

До человека уж очень медленно все доходит. Что поделаешь?

Здравствуйте, hattab, Вы писали:


H>>>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.

kuj>>Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?

H>ignore off

H>Ты так туп, что не можешь прочитать, что написано COM, как вы их называете. Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.

H>ignore on

Скорее ты так туп, что не можешь выразить свою мысль:

"В нативной Delphi тип интерфейсов один -- COM, как вы его называете"

Один это не два, не три и не пять. Один это один. Учись выражать свои мысли.

Здравствуйте, gandjustas, Вы писали:

H>>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
G>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
G>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
G>Можешь не спорить, это факт.

Вот что по теме нашел http://hallvards.blogspot.com/2006/04/pure-interfaces-in-delphi.html. Вот так-то... Hattab не только в .NET не бум-бум, он еще и в Delphi элементарного не знает.

Здравствуйте, WolfHound, Вы писали:

WH>Вот от тебя ничего кроме первого абзаца не слышно.

Уговорил. Есть задача, написать сервер XML-RPC. Реализовать гибкую систему API (подключение/отключение методов, группы методов в любой момент работы сервера). Как реализуются методы мы не знаем. Это могут быть и нативные объекты подключенные в виде некого API, это могут быть скриптовые методы, это может быть все что угодно. Сервер должен уметь валидировать список параметров методов, запрашиваемых на выполнение, с учетом возможной перегрузки методов и наличия дефолтных параметров. Сервер не должен навязывать какой либо идеологии в реализации подключаемых методов. Реализации API должны позволять расширять свою функциональность для получения дополнительных возможностей, например: протоколирования, перехвата, построения справочной информации, самоописания.

Это очень краткое описание. Для справки: мои парент и чилды, это абстракция ServiceObject (некое API) и MethodHandler (обработчик метода). ServiceObject являет собою некое API (какое, мы не знаем), и для каждого метода имеет MethodHandler.

Для примера кусочек реализации:

...
Server.RegisterHandlers(TIntrospectionAPI.Create);
Server.RegisterHandlers(TDescriberAPI.Create);
Server.RegisterHandlers(TBoxcarringAPI.Create);
...

И что? Стало сильно понятнее?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Сергей, Вы писали:

С>>.NET, конечно, занял большую часть ниши Delphi.
С>>Но не полностью, нет.
G>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
G>Какая часть ниши Delphi еще не занята .NET?

— Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют.
— Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие.
— Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.

Здравствуйте, kuj, Вы писали:

Ответил на аналогичный вопрос другому участнику форума:
http://rsdn.ru/Forum/Default.aspx?mid=2938057&flat=0

Автор: Сергей
Дата: 04.05.08

Здравствуйте, gandjustas, Вы писали:

H>>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?
G>Ну хватит уже показывать свое незнание.
G>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа.

В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.

G>Из одного твоего предложения сразу видно что: а)ты не работал с .NET языками б)ты не работал на С++ в)ты не работал с COM не в Delphi г)ты плохо понимаешь зачем вообще нужны интерфейсы.

Прекрати расширять сознание. Ты обкурился.

H>>>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
G>>>А парент просто хранит ссылки на детей?
H>>Что значит просто? Ну да, имеет список своих чилдов.
G>Тогда такая ситуация нормально разрулится GC.

Ты как б... твердолобый. Я тебе про Фому, ты мне про Ерему...

G>>>>>ЗЫ С выделенным категорически не согласен.
H>>>>Да-да, ведь рефакторинг это круто
G>>>Не в рефакторигне дело.
H>>А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием.
G>Честно гворя даже не хочу тебе объяснять

А и не стоит пожалуй...

Здравствуйте, gandjustas, Вы писали:

DOO>>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
kuj>>>Кроме Delphi. Ее мини-ниша полностью занята .NET

С>>.NET, конечно, занял большую часть ниши Delphi.
С>>Но не полностью, нет.
G>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.

Я смотрю, ты с kuj'ем, два сапога -- пара. Скоро тоже отправишься в игнор.

G>Какая часть ниши Delphi еще не занята .NET?

Нативные десктоп-приложения, без тормозного рантайма и диких требований к мемори.

Здравствуйте, gandjustas, Вы писали:

H>>Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.
G>Каждый объект, реализующий интерфейс преобретает семантику COM-объекта. То есть при использовании становится фактически COM-объектом.
G>Поэтому итнерфейсы в Delphi — именно COM-интерфейсы.
G>Можешь не спорить, это факт.

Не стоит бравировать своим невежеством.

COM-интерфейс:

ICOMInterface = Interface(IUnknown)
[...]

 Procedure GetAppName : WideString; StdCall;

End;

Не COM-интерфейс:

INonCOMInterface = Interface(IUnknown)
[...]

 Procedure GetAppName : AnsiString;
 Procedure ClearList(AList : TList);

End;

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, WolfHound, Вы писали:

WH>>Вот от тебя ничего кроме первого абзаца не слышно.

H>Уговорил. Есть задача, написать сервер XML-RPC. Реализовать гибкую систему API (подключение/отключение методов, группы методов в любой момент работы сервера). Как реализуются методы мы не знаем. Это могут быть и нативные объекты подключенные в виде некого API, это могут быть скриптовые методы, это может быть все что угодно. Сервер должен уметь валидировать список параметров методов, запрашиваемых на выполнение, с учетом возможной перегрузки методов и наличия дефолтных параметров. Сервер не должен навязывать какой либо идеологии в реализации подключаемых методов. Реализации API должны позволять расширять свою функциональность для получения дополнительных возможностей, например: протоколирования, перехвата, построения справочной информации, самоописания.

H>Это очень краткое описание. Для справки: мои парент и чилды, это абстракция ServiceObject (некое API) и MethodHandler (обработчик метода). ServiceObject являет собою некое API (какое, мы не знаем), и для каждого метода имеет MethodHandler.

H>Для примера кусочек реализации:
H>

H>...
H>Server.RegisterHandlers(TIntrospectionAPI.Create);
H>Server.RegisterHandlers(TDescriberAPI.Create);
H>Server.RegisterHandlers(TBoxcarringAPI.Create);
H>...
H>

H>И что? Стало сильно понятнее?

Конечно стало понятнее.
Еще раз убедился что подсчет ссылок в твоем решении то как раз ошибка выбора платформы.

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Сергей, Вы писали:

С>>>.NET, конечно, занял большую часть ниши Delphi.
С>>>Но не полностью, нет.
G>>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
G>>Какая часть ниши Delphi еще не занята .NET?

С>- Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют.
С>- Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие.
С>- Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.

Ты уверен что это ниши Delphi ?
Для таких задач по большей части C++ используют.

Здравствуйте, Сергей, Вы писали:

С>>>.NET, конечно, занял большую часть ниши Delphi.
С>>>Но не полностью, нет.
G>>Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
G>>Какая часть ниши Delphi еще не занята .NET?

С>- Шаровара. Дотнету уже много лет, а шароварную программу, написанную на дотнете, встретить не так просто. Ну, и судя по флеймам "Шаровара на С# — реально ли?", дотнет шароварщики не очень жалуют.
Какого года твои сведенья? Либо .NET, либо C++. На Delphi единицы и в основном это legacy-проекты.

С>- Просто пример — Inno Setup. Он написан на делфи, писать аналог на дотнете — на данный момент не очень осмысленное занятие.

Есть Wix, который лучше за счет простоты использования в continous integration процессе.

С>- Другой пример, из своего опыта. Не так давно писал GINA (модуль для Winlogon) на Delphi. Нужен был довольно-таки богатый интерфейс. Получилось быстро, все довольны. Возможно ли было написать такое на дотнете — думаю, нет, т.к. GINA — это DLL, экспортирующая строго определенный набор функций, которую загружает непосредственно winlogon.

Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:
G>>Какая часть ниши Delphi еще не занята .NET?

H>Нативные десктоп-приложения, без тормозного рантайма и диких требований к мемори.
Насмешил. Скачай Paint.NET и попробуй тоже на Delphi повторить.

Здравствуйте, hattab, Вы писали:

H>COM-интерфейс:
H>

H>ICOMInterface = Interface(IUnknown)
H>[...]

H> Procedure GetAppName : WideString; StdCall;

H>End;
H>

H>Не COM-интерфейс:
H>

H>INonCOMInterface = Interface(IUnknown)
H>[...]

H> Procedure GetAppName : AnsiString;
H> Procedure ClearList(AList : TList);

H>End;
H>

А то что они наследуют IUnknown ничего не значит уже?

Здравствуйте, hattab, Вы писали:

G>>Какая часть ниши Delphi еще не занята .NET?

H>без тормозного рантайма и диких требований к мемори.

Ты точно про Delphi говоришь?

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?
G>>Ну хватит уже показывать свое незнание.
G>>В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа.
H>В Delphi это тоже есть (CanFlyIntf := FlyObject) (хотя семантические различия мне пофигу), да вот прикол: ты не можешь использовать такое приведение если не знаешь к чему приводить нужно. Расширяй сознание.

Новое слово в ООП — приведение типов, когда не заешь к чему приводить....

Здравствуйте, gandjustas, Вы писали:

G>Ты уверен что это ниши Delphi ?
G>Для таких задач по большей части C++ используют.

Скажем так, на мой взгляд, это области, в которых примененить Delphi зачастую оказывается эффективнее, чем дотнет.

Здравствуйте, gandjustas, Вы писали:

H>>И что? Стало сильно понятнее?

G>Конечно стало понятнее.
G>Еще раз убедился что подсчет ссылок в твоем решении то как раз ошибка выбора платформы.

Я знаю, что ты ничего не понял. Прибереги свою желчь.

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, gandjustas, Вы писали:

G>>Ты уверен что это ниши Delphi ?
G>>Для таких задач по большей части C++ используют.

С>Скажем так, на мой взгляд, это области, в которых примененить Delphi зачастую оказывается эффективнее, чем дотнет.
Может быть, но это не ниша Delphi как ни крути.