Здравствуйте, Mamut, Вы писали:
M> С чего это вдруг они будут являться пшиком? Интерфейсы — не более, чем реализация множественного наследования в языках, где множественного наследования нет (например, в Delphi). При чем тут COM'овские методы?
Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки.
Здравствуйте, Mamut, Вы писали:
_>>Это в С++. Интерфейсы Delphi не являются абстрактными классами. Если тебе нужен абстрактный класс — сделай абстрактный класс, никто не мешает. Безо всяких IUnknown.
M>Дело в том, что в Delphi нет множественного наследования, и интерфейсы — это единственный способ задать разное поведение обхекту. Тольков от облом — это поведение будет гвоздями прибито к DOM'у.
Компилятор Delphi неявно вызывает AddRef и Release при работе с интерфейсами. Без QueryInterface для простых внутренних интерфейсов можно обойтись, а AddRef и Release должны быть обязательно как-то реализованы. Собственно и всё.
Здравствуйте, hattab, Вы писали:
MM>> H>Я уже сказал, что эту темя для себя закрыл. Ты можешь найти ответ если перечитаешь написанное ранее. MM>> Ты написал, что речь идет о какой-то там "нативности". Так вот я и не пойму: что ты вкладываешь в это понятие? H>Менеджед и натив различаешь? Это оно.
Вроде приводили в пример С++. Вроде нативный язык. Не?
MM>> Также был вопрос: что мешает компилятору самому генерить эти три метода? H>Вопрос зачем? Иногда бывает выгодно самому релизить некоторые из этих методов, преинтересные вещи делать удается, доложу я вам (см. RIO.TRIO.QueryInterface и как там формируются интерфейсные таблицы для поддержки SOAP).
Еще раз повторю. Затем, что мне эти методы не нужны. Их нет в моем контракте. Пофиг мне, что с ними кто-то может делать интересные вещи. Мне они зачем, м?
Здравствуйте, lazy_walrus, Вы писали:
_>>>И спорящий с тобой правильно делает — в Delphi жизнь TObject'ов никак не управляется. Единственный способ, с помощью которого в Delphi можно например реализовать RAII — это интерфейсы работающие через подсчёт ссылок. MM>>Вот это интересно. Т.е. теперь оказывается, что интерфейсы в Delphi введены для RAII? _>С какого перепоя такое умозаключение?
Выделил. Но скажу сразу, что я почему-то пропустил слово "например". Если RAII был просто примером, то ладно.
Здравствуйте, hattab, Вы писали:
H>Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки.
Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а?
Здравствуйте, MxMsk, Вы писали:
H>>Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки. MM>Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а?
Он просто не может найти нужный аргумент ни на хоботе, ни на хабре, потому повторяет чьи то фразы.
Здравствуйте, hattab, Вы писали:
M>> С чего это вдруг они будут являться пшиком? Интерфейсы — не более, чем реализация множественного наследования в языках, где множественного наследования нет (например, в Delphi). При чем тут COM'овские методы?
H>Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки.
Нет там ничего страшного. Упрощенный до предела бинарный стандарт.
Здравствуйте, MxMsk, Вы писали:
MM> Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а?
А тебя коим боком задевает? Это мое личное дело, тем более, что есть за что Что-то ты к Мамуту не лезешь, когда он Шеридана поливает. Искатель справедливости, мля
Здравствуйте, Ikemefula, Вы писали:
I> MM>Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а?
I> Он просто не может найти нужный аргумент ни на хоботе, ни на хабре, потому повторяет чьи то фразы.
Здравствуйте, Ikemefula, Вы писали:
I> M>> С чего это вдруг они будут являться пшиком? Интерфейсы — не более, чем реализация множественного наследования в языках, где множественного наследования нет (например, в Delphi). При чем тут COM'овские методы?
I> H>Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки.
I> Нет там ничего страшного. Упрощенный до предела бинарный стандарт.
Здравствуйте, MxMsk, Вы писали:
MM> H>Менеджед и натив различаешь? Это оно.
MM> Вроде приводили в пример С++. Вроде нативный язык. Не?
Ты в курсе, что C++ это еще не вся нативная среда? О взаимодействии подумай. Ну я же об этом писал уже, ну?
MM> MM>> Также был вопрос: что мешает компилятору самому генерить эти три метода?
MM> H>Вопрос зачем? Иногда бывает выгодно самому релизить некоторые из этих методов, преинтересные вещи делать удается, доложу я вам (см. RIO.TRIO.QueryInterface и как там формируются интерфейсные таблицы для поддержки SOAP).
MM> Еще раз повторю. Затем, что мне эти методы не нужны. Их нет в моем контракте. Пофиг мне, что с ними кто-то может делать интересные вещи. Мне они зачем, м?
Не нужны — не реализуй Выбери предка с реализацией или делегируй. Тоже мне проблема
Здравствуйте, hattab, Вы писали:
MM>> Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а? H>Что-то ты к Мамуту не лезешь, когда он Шеридана поливает.
им можно. я так вообще серьёзно думаю, что они в жаббере договариваются кто кого где и как ссаными тряпками гонять будет.
Здравствуйте, Antikrot, Вы писали:
MM>>> Слушай, у тебя, что не ответ Мамуту, то попытка оскорбить. Может сбавишь обороты, а? H>>Что-то ты к Мамуту не лезешь, когда он Шеридана поливает. A>им можно. я так вообще серьёзно думаю, что они в жаббере договариваются кто кого где и как ссаными тряпками гонять будет.
Ты святой
_>>>Это в С++. Интерфейсы Delphi не являются абстрактными классами. Если тебе нужен абстрактный класс — сделай абстрактный класс, никто не мешает. Безо всяких IUnknown.
M>>Дело в том, что в Delphi нет множественного наследования, и интерфейсы — это единственный способ задать разное поведение обхекту. Тольков от облом — это поведение будет гвоздями прибито к DOM'у.
_>Компилятор Delphi неявно вызывает AddRef и Release при работе с интерфейсами.
Зачем?
_>Без QueryInterface для простых внутренних интерфейсов можно обойтись, а AddRef и Release должны быть обязательно как-то реализованы.
M>> С чего это вдруг они будут являться пшиком? Интерфейсы — не более, чем реализация множественного наследования в языках, где множественного наследования нет (например, в Delphi). При чем тут COM'овские методы?
H>Вот-вот, я и говорю, нифига ты не понимаешь... QueryInterface страшная сила, если начать думать, а не повторять зазубренные формулировки.
При чем тут QueryInterface к множественному наследованию? Правильно, оно к нему вообще никакого отношения не имеет. Оно имеет отношение только к COM'у
M>Это грязный хак для работы с COM-ом. Не знаю, как сейчас, но в Delphi не было не-COM интерфейсов.
По-моему, это вполне себе чистый хак для работы с COM-ом.
Такой реализацией Хейльсберг дал возможность использовать ком-объекты в Дельфи без ручного подсчёта ссылок и пользования QueryInterface.
Какие у него были варианты?
1. Сделать два типа интерфейсов: унаследованные от IUnknown и все остальные. Компилятор отслеживает поведение IUnknown-based, автоматически подсчитывая ссылки и преобразуя приведение типов к QueryInterface. Для "обычных" интерфейсов он этого не делает.
Такая политика может приводить к трудноуловимым глюкам в тех случаях, когда класс реализует сразу несколько интерфейсов. Получается, разные ссылки на этот объект будут вести себя по-разному. Вот мы сохраняем ссылку на "обычный" интерфейс. Как знать, вдруг за ней скрывается объект с поддержкой IUnknown? Проверять ли это и подсчитывать ли ссылки?
Как делать приведения к интерфейсу? Вот мы приводим "обычный" интерфейс к IUnknown-based. Возможно, он реализован через агрегацию, которая встроена в язык. Стало быть, обычный каст даст неверный результат — нужно лезть в QueryInterface.
В общем, что-то не клеится такая автоматика. Получаем переусложнение на ровном месте, и паранойю компилятора во всех местах использования интерфейсов типа "а вдруг там сзади COM?"
2. Сделать ровно один тип интерфейсов. IUnknown — такой же, как и все; никакой магии нет. Получается, для банальной работы с ком-объектами нужно везде руками писать AddRef/Release/QueryInterface. Постоянно помнить о том, что приведение типов через каст может работать-работать, а потом вдруг перестать — если реализация данного конкретного интерфейса изменилась на агрегацию.
Работать — работает, но как-то грубо по отношению к девелоперам. Это примерно то же, что и поддержка COM в чистом C: реализовать можно, но помощи от компилятора нет.
3. Принудительно сделать все интерфейсы ком-совместимыми. В итоге за счёт весьма небольшой цены (фактически, припиливания 4х байт к каждому объекту, реализующему хоть какой-то интерфейс) имеем очень хорошую поддержку как разработки COM-классов, так и использования; при этом компилятор достаточно прямолинеен и предсказуем.
На всякий случай напомню, что дедушка Хейльсберг знаменит как раз тем, что он специализируется на написании кода для пользы, а не для красоты. Его задачей была не абстрактная реализация красивой идеи интерфейсов, а облегчение жизни виндовс-девелоперам. Ну как в C# 3.0 была задача "сделать лёгким взаимодействие с СУБД", так и в Дельфи ставилась задача "сделать лёгким взаимодействие с COM". Тогда это было более важным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Какие у него были варианты? S>1. Сделать два типа интерфейсов: унаследованные от IUnknown и все остальные. Компилятор отслеживает поведение IUnknown-based, автоматически подсчитывая ссылки и преобразуя приведение типов к QueryInterface. Для "обычных" интерфейсов он этого не делает. S>Такая политика может приводить к трудноуловимым глюкам в тех случаях, когда класс реализует сразу несколько интерфейсов. Получается, разные ссылки на этот объект будут вести себя по-разному. Вот мы сохраняем ссылку на "обычный" интерфейс. Как знать, вдруг за ней скрывается объект с поддержкой IUnknown? Проверять ли это и подсчитывать ли ссылки? S>Как делать приведения к интерфейсу? Вот мы приводим "обычный" интерфейс к IUnknown-based. Возможно, он реализован через агрегацию, которая встроена в язык. Стало быть, обычный каст даст неверный результат — нужно лезть в QueryInterface.
S>В общем, что-то не клеится такая автоматика. Получаем переусложнение на ровном месте, и паранойю компилятора во всех местах использования интерфейсов типа "а вдруг там сзади COM?"
S>2. Сделать ровно один тип интерфейсов. IUnknown — такой же, как и все; никакой магии нет. Получается, для банальной работы с ком-объектами нужно везде руками писать AddRef/Release/QueryInterface. Постоянно помнить о том, что приведение типов через каст может работать-работать, а потом вдруг перестать — если реализация данного конкретного интерфейса изменилась на агрегацию. S>Работать — работает, но как-то грубо по отношению к девелоперам. Это примерно то же, что и поддержка COM в чистом C: реализовать можно, но помощи от компилятора нет.
S>3. Принудительно сделать все интерфейсы ком-совместимыми. В итоге за счёт весьма небольшой цены (фактически, припиливания 4х байт к каждому объекту, реализующему хоть какой-то интерфейс) имеем очень хорошую поддержку как разработки COM-классов, так и использования; при этом компилятор достаточно прямолинеен и предсказуем.
4. Сделать все интерфейсы простыми, без магии, а для магии добавить отдельную фичу языка, позволяющую делать автодеструкцию, причем не только для интерфейсов, а универсально.
И Хейлсберг сотоварищи, кстати, знаменит еще и тем, что вместо прибивания гвоздями к основному языку SQL, как это делали многие до него, он придумал куда как более генерализованный LINQ. Который сейчас используется вообще без БД в огромном количестве мест. И интерфейсы в Дельфи так и остались в основном средством СОМ интеропа.
Здравствуйте, hattab, Вы писали:
H>Несмотря на то, что IMyIntf наследуется от IInterface (IUnknown), сам он не является COM-интерфейсом т.к. не имеет собственного GUID'а.
GUID нужен для регистрации интерфейса и работы через QueryInterface. Однако QI не единственный способ получения ссылки на стаб интерфейса. Вполне работает в СОМ куда более банальный вариант:
interface IGuidIface
{
INoGuidIface Get();
// Или даже так
IUnknown MyQueryInterface(string ifaceName);
}
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> GUID нужен для регистрации интерфейса и работы через QueryInterface. Однако QI не единственный способ получения ссылки на стаб интерфейса. Вполне работает в СОМ куда более банальный вариант: НС>
НС> interface IGuidIface
НС> {
НС> INoGuidIface Get();
НС> // Или даже так
НС> IUnknown MyQueryInterface(string ifaceName);
НС> }
НС>
Только это будет уже не COM-интерфейс. Я ведь уже приводил цитату из PSDK:
COM interfaces are strongly typed. Every interface has its own interface identifier (a GUID), which eliminates the possibility of duplication that could occur with any other naming scheme.
