Расширяемый интерфейс, что это такое?

[ger_kar]

Собственно обратил внимание на атрибут библиотеки типов nonextensible
В MSDN на эту тему нашел следующее:

The [nonextensible] attribute specifies that the IDispatch implementation includes only the properties and methods listed in the interface description and cannot be extended with additional members at run time. (By default, Automation assumes that interfaces may add members at run time; that is, it assumes they are extensible.)

Атрибут [не расширяемый] указывает, что реализация IDispatch включает только те свойства и методы, перечисленные в описании интерфейса и не может быть расширена дополнительными членами во время выполнения. (По умолчанию, Автоматизация предполагает, что интерфейсы могут добавлять члены во время выполнения, т.е., предполагается, что они являются расширяемыми)

И стало интересно, что же это такое? Может это ОНО САМОЕ?. Или же это что то другое? Информации по этому вопросу я особо не нашел. Я реализовал затею с добавлением новых методов, как элементов коллекции и их вызов через IDispatch, но проблема в следующем. Если вызывать все методы через позднее связывание (объявлять переменную As Object), то все прекрасно работает, но это неудобно и страдает производительность, так как даже имеющийся статический набор методов вызывается через IDispatch и отсутствую подсказки, что есть нехорошо. А если объявить переменную с типом нужного интерфейса, то тогда если вызывать методы не описанные в TLB, то проект даже компилироваться не хочет. И еще момент. Вызов через IDispatch работает хоть с атрибутом nonextensible, хоть без него, а по типу раннего связывания не работает не так и не сяк. А хотелось бы следующее (если такое конечно вообще возможно) - Объявлять переменную нужного типа, чтобы вызов был ранним, а при отсутствие нужных методов в описании была попытка вызова метода через IDispatch.

[Хакер]

Объявлять переменную нужного типа, чтобы вызов был ранним, а при отсутствие нужных методов в описании была попытка вызова метода через IDispatch.

Нет, потому что это дискредитирует идею интерфейсов.

[ger_kar]

А зачем тогда nonextensible? Какую роль он (этот атрибут) вообще играет?

[Хакер]

Ну, он говорит, что результат GetIDsOfNames и успешность Invoke можно кешировать. Если вызов не получился сейчас, потому что «нет такого метода», то в следующий раз можно даже не пытаться.

В общем случае результат GetIDsOfNames кешировать нельзя — нужно каждый раз делать запрос.

Хотя кеширование с IDispatch, как уже упоминал tyomitch, штука не простая: нужно кешировать на уровне объекта, а не на уровне интерфейса или класса, потому что у разных объектов dispid-ы одних и тех же членов могут отличаться. Поэтому каждому объекту нужно сопоставлять свою собственную кеш-таблицу, что не так-то просто и эффективность.

Но эффективность такого подхода резко возрастает, например, в случае маршаллинга вызовов через границы процесса или (лучше) через границы машин по сети, то есть при использовании DCOM. Гонять по сети постоянно запросу GetIDsOfNames нее самое хорошее дело, а тут мы даёт proxy-объекту возможность запоминать результат преобразования имён в dispid-ы и помнить, какие члены есть, а каких точно нет.

Причём, я не говорю, что текущая реализация proxy-stub-механизма так делает. Но этот аттрибут определённо даёт возможность так сделать, в том числе и написав собственый маршаллер.

[ger_kar]

Спасибо за разъяснения
Интересно, а реализация форм в VB6 по какому принципу сделана? По сути формы же имеют некий стандартный интерфейс, который тоже можно расширить добавив свои Public методы. Правда это все делается на этапе написания кода, и при таком подходе наверное проще и лучше расширить Vtbl.

[Vi]

Объявлять переменную нужного типа, чтобы вызов был ранним, а при отсутствие нужных методов в описании была попытка вызова метода через IDispatch.

Нет, потому что это дискредитирует идею интерфейсов.

Сами эти интерфейсы (IDispatch и далее dispinterface) придуманы и введены для вызова методов в отсутствие их описания, так что эта идея ger_kar'а имеет право на жизнь и существует в реализации. Причём dispinterface введены для возможного контроля кода на этапе компиляции, но реально не могут быть использованы тем же VB, потому что на одном объекте VB не сможет вызвать методы разных dispinterface.

[Хакер]

Vi, я не понял полностью смысл твоего поста, а ты, видимо, не понял мой.

VB имеет ссылку ref, объявленную As ISomething.
VB смотрит TLB и видит, что ISomething унаследован от IDispatch.
VB пытается скомпилировать ref.NonExistantMethod() и отказывается это компилировать.

То, что хочет ger_kar — чтобы VB не отказывался это компилировать, видя унаследованность от IDispatch, а скомпилировал бы это в пару GetIDsOfNames+Invoke.

Но идея, что было бы неплохо, если бы VB поступал так, дискредитируют идею использования интерфейсов. Потому что идея во многом — в типизации, в сохранении определённой степени контроля над кодом и в отлове тех ошибок, которые можно отлавить на стадии компиляции, именно на этой стадии.

Если бы VB поступал так, как хочет ger_kar, то выгода от использования конкретных интерфейсов для объявления объектных ссылок (в противовес использованию типа Object или Variant для объявления любых объектных ссылок) сводилась бы к автодополнению и увеличению производительности там, где можно применить раннее связывание.

Или другими словами: инструмент, который ругнётся на ошибочный вызов несуществующего метода на стадии компиляции, но тем не менее оставляет программисту возможность вызывать возможно несуществующий метод — намного лучше инструмента, который молча проглотит любой вызов (даже выглядщий как ошибочный), производя код, который во время выполнения всё-таки попытается достучаться до с-виду-несуществующего метода, при этом лишая программиста возможности быть подвергнутым бдительному контролю со стороны компилятора.

Или ещё другими словами: неявное использование позднего связывания там, где предполагается использование раннего связывания, но нужный член отсутствует, намного хуже явного использования того связывания, какого желает программист.

Или ещё короче: явное лучше неявного.

Что касается этого:

но реально не могут быть использованы тем же VB, потому что на одном объекте VB не сможет вызвать методы разных dispinterface.

То возникает вопрос: с чего это вдруг? Здесь ты ошибаешься.

Во-первых, VB прекрасно поддерживает disp-интерфейсы.

Вообще, я не знаю, но относительно интерфейсов существует огромное количество идиотских мифов, касающийся того, что VB не поддерживает то одно, то другое. Хотя в реальности с поддержкой разных видов интерфейсов у VB всё обстоит намного лучше, чем у тех, кто невежественно заявляет об отсутствии такой поддержки.

Один старый миф гласит, что VB может работать только с интерфейсами, унаследованными от IDispatch. А с теми, которые не унаследованы от IDispatch, а унаследованы прямо или косвенно от IUnknown (но без IDispatch в цепочке наследования) работать якобы не может. Это чушь и профанация. Даже GSerg написал в своё время статью «Работа с объектами, не поддерживающими IDispatch», где извращался с ассемлерными вставками, вместо того, чтобы просто подключить к проекту подходящую TLB с описанием нужного интерфейса, и где как раз заявляется, что по нормальному с такими объектами работать нельзя (что ЛОЖНО).

Теперь я вижу миф, что VB не работает с disp-интерфейсами.

Это всё ерунда.

VB прекрасно работает с интерфейсами, не унаследованными от IDispatch. Вне зависимости от того, унаследован интерфейс от IDispatch или нет, VB нужно просто иметь описание этого интерфейса (в виде TLB). Всё — этого достаточно, чтобы объявлять типизированные ссылки и осуществлять через них вызовы по механизму раннего связывания.

VB прекрасно работает с самим интерфейсом IDispatch — для этого есть встроенный типа Object. Этого достаточно, чтобы объявлять AsObject-ссылки и осуществлять через них вызовы через позднее связывание.

VB прекрасно работает с интерфейсами, унаследованными от IDispatch, то есть такими, которые дополняют IDispatch новыми методами. Это просто частный случай пункта-1.

VB прекрасно работает с dual-интерфейсами, то есть с такими, когда по сути существует связанная пара из обычного и disp-интерфейса. В случае dual-интерфейсов VB позволяет использовать эти интерфейсы при объявлении объектных ссылок и для осуществения вызовов. При этом для вызова VB всегда отдаёт предпочтение обычному интерфейсу (vtable-интерфейсу), а тот факт, что есть ещё сопутствующий disp-интерфейс просто игнорируется. На самом деле не абсолютно всегда, а всегда, кроме случая, когда вызов делает в коде с применением т.н. именованных аргументов.

И наконец VB прекрасно работает с голыми disp-интерфейсами, то есть такими, у которых нет (то есть нет вообще) соответствующего парного обыкновенного интерфейса (vtable-интерфейса). VB позволяет использовать такие интерфейсы для объявления объектных ссылок и для осуществления вызовов членов. В

Помимо всего этого (я специально оставил на закуску), VB не просто позволяет работать с чужими объектами, поддерживающими все вышеперечисленные случаи интерфейсов, позволяя программисту декларировать типизированные объектные ссылки и вызывать метода через них. Нет, помимо этого VB допускают, что VB-шные объекты (написанные на VB классы) могут имплементировать все эти случаи подвиды интерфейсов.

Так что VB-шный класс может имплементировать интерфейс, не унаследованный от IDispatch, а унаследованный сразу от IUnknown.
VB-шный класс априори имплементирует IDispatch.
VB-шный класс может имплементировать интерфейс, унаследованный от IDispatch и дополненный новыми методами.
VB-шный класс может имплементировать dual-интерфейс.
VB-шный класс может имплементировать голый disp-интерфейс (голый в смысле не-dual), у которого отсутствует раннесвязываемая версия.

VB-шный класс может имплементировать сразу кучу разных disp-интерфейсов, а не ограничиваться одним.

VB может работать со своими объектами, реализующими сразу кучу disp-интерфейсов.
VB может работать с чужими объектами, реализующими сразу кучу disp-интерфейсов.

После всего этого утверждение

но реально не могут быть использованы тем же VB, потому что на одном объекте VB не сможет вызвать методы разных dispinterface.

выглядит странно.

[Vi]

Vi, я не понял полностью смысл твоего поста, а ты, видимо, не понял мой.

VB имеет ссылку ref, объявленную As ISomething.
VB смотрит TLB и видит, что ISomething унаследован от IDispatch.
VB пытается скомпилировать ref.NonExistantMethod() и отказывается это компилировать.

Вот прям сейчас для VB6 я запустил из студии и скомпилировал и запустил код в project1.exe:

Код: Выделить всё

Private Sub Form_Load()
  Dim a As AdemCAMLib.IAdemTDMManager
  Set a = GetObject(, "Adem.TDMManager")
  Call a.xxxx
End Sub


Оба кода выдают на строке "Call a.xxxx" ошибку времени выполнения:

Run-time error '438':
Object doesn't support this property or method

Так что VB пропускает неизвестные имена для позднего связывания или по иной причине.

Остальное потом прочту.

[Хакер]

Так что VB пропускает неизвестные имена для позднего связывания или по иной причине.

Это потому что IAdemTDMManager — это как раз disp-интерфейс. То есть он и так используется позднее связывание.
Но для просто интерфейсов, у которых для доступа к членам используются раннее связывание, автоматического фолбека на использование позднего связывания нет.

[Хакер]

Объявлять переменную нужного типа, чтобы вызов был ранним, а при отсутствие нужных методов в описании была попытка вызова метода через IDispatch.

Нет, потому что это дискредитирует идею интерфейсов.

С учётом вышесказанного, этот вопрос и ответ на него остаются актуальными.

Но если в изначальном вопросе заменить «чтобы вызов был ранним», на «чтобы вызов был поздним со связыванием по dispid-у», то ответ будет «можно». Надо использовать dispinterface.

Пример:

Код: Выделить всё

Private Sub Form_Load()
    Dim pic_vtbl As IPicture
    Dim pic_disp As IPictureDisp
   

    Set pic_vtbl = Me.Picture
    Set pic_disp = Me.Picture
   
    ' Если раскомментировать: будет Compile Error
'    pic_vtbl.Muhajahahaha
   
    ' Здесь будет runtime error
    pic_disp.Muhajahahaha
   
End Sub


(Разница между IPicture и IPictureDisp как раз и состоит в том, что первый использует раннее связывание и вызовы идут через vtable, а второй это disp-интерфейс, вызовы идут через IDispatch::Invoke по dispid-ам)

[Vi]

Это потому что IAdemTDMManager — это как раз disp-интерфейс. То есть он и так используется позднее связывание.
Но для просто интерфейсов, у которых для доступа к членам используются раннее связывание, автоматического фолбека на использование позднего связывания нет.

Код: Выделить всё

   [
      object, dual, pointer_default(unique)
      , uuid(D7585674-18D4-11D3-A10F-004095426E66)
      , helpstring("AdemTDM Manager Interface")
   ]
   interface IAdemTDMManager : IDispatch

Вот как раз и не диспинтерфейс.

[Vi]

Но если в изначальном вопросе заменить «чтобы вызов был ранним», на «чтобы вызов был поздним со связыванием по dispid-у», то ответ будет «можно». Надо использовать dispinterface.
Пример:

Код: Выделить всё

Private Sub Form_Load()
    Dim pic_vtbl As IPicture
    Dim pic_disp As IPictureDisp
   

    Set pic_vtbl = Me.Picture
    Set pic_disp = Me.Picture
   
    ' Если раскомментировать: будет Compile Error
'    pic_vtbl.Muhajahahaha
   
    ' Здесь будет runtime error
    pic_disp.Muhajahahaha
   
End Sub


(Разница между IPicture и IPictureDisp как раз и состоит в том, что первый использует раннее связывание и вызовы идут через vtable, а второй это disp-интерфейс, вызовы идут через IDispatch::Invoke по dispid-ам)

Код: Выделить всё

[
    object,
    uuid(7BF80980-BF32-101A-8BBB-00AA00300CAB),
    pointer_default(unique)
]
interface IPicture : IUnknown

[
    object,
    uuid(7BF80981-BF32-101A-8BBB-00AA00300CAB),
    pointer_default(unique)
]
interface IPictureDisp : IDispatch
{
    typedef IPictureDisp * LPPICTUREDISP;
}


IPicture - это чистый интерфейс, он вообще к механизму Invoke не имеет отношения. Никакого неизвестного метода в этом интерфейсе нет и быть не может. Поэтому правильно генерится ошибка.

IPictureDisp - это дуальный интерфейс, - совсем даже не диспинтерфейс, который вообще не наследует по синтаксису никакого интерфейса в IDL/ODL, - и имеет специальное описание в виде описания чистого интерфейса и диспинтерфейса. Это такой же интерфейс, как и выше использованный IAdemTDMManager.

[Хакер]

IPicture - это чистый интерфейс, он вообще к механизму Invoke не имеет отношения.

Я не говорил обратного.

IPictureDisp - это дуальный интерфейс, - совсем даже не диспинтерфейс,

Не знаю, откуда ты это взял и откуда взялся твой IDL-код наверху.
Возможно мы смотрим разные TLB. Я смотрю библиотеку stdole2.tlb, которую использует VB6. В этой библиотеке IPicture — это чистый интерфейс (я нигде не говорил обратного), а IPictureDisp — disp-интерфейс (недуальный). Если быть совсем точным, то в ней IPictureDisp это алиас на disp-интерфейс «Picture».

А вот твой результат насчёт IAdemTDMManager интересный, я сейчас его анализирую.

[Vi]

VB может работать со своими объектами, реализующими сразу кучу disp-интерфейсов.
VB может работать с чужими объектами, реализующими сразу кучу disp-интерфейсов.
После всего этого утверждение

но реально не могут быть использованы тем же VB, потому что на одном объекте VB не сможет вызвать методы разных dispinterface.

выглядит странно.

Да, тут я ступил, уже не помню, что хотел подчеркнуть. Наверное, то, что невозможно передать диспинтерфейсы через VARIANT корректно, потому что маршаллинг этого указателя идёт через стандартное поле для IDispatch и не содержит информации для его перевода обратно в нужный диспинтерфейс.

А так, если выполнить преобразование в нужный диспинтерфейс, то все его методы будут доступны.

[Vi]

Не знаю, откуда ты это взял и откуда взялся твой IDL-код наверху.

Это часть кода из C:\Program Files\Microsoft Visual Studio\VC98\Include\OCIDL.IDL

PS
Диспинтерфейс - это такой интерфейс, который описывается в IDL/ODL, например, так:

Код: Выделить всё

[
    hidden,
    uuid(3050f55a-98b5-11cf-bb82-00aa00bdce0b)
]
dispinterface DispHTMLStyle


[Хакер]

Это часть кода из C:\Program Files\Microsoft Visual Studio\VC98\Include\OCIDL.IDL

Но VB использует stdole2.tlb из system32, а там всё так, как я описал.

[Хакер]

Похоже в этой теме каждый налажал, включая топик-стартера.

Я попробовал проследить разницу. Интерфейсы, производимые самим VB являются дуальными, но они не позволяют вызывать левые отсутствующие методы.
Интерфейс IAdemTDMManager, который выложил Vi, тоже дуальный, но со слов Vi получается, то VB позволяет вызов отсутствующего метода.

В чём разница? Вероятно в атрибутах. Я попытался найти момент смены поведения.

И, внимание!

Оказазывается, что разницу в поведении даёт наличие или отсутствие того самого атрибута nonextensible, о котором ger_kar изначально писал:

Вызов через IDispatch работает хоть с атрибутом nonextensible, хоть без него, а по типу раннего связывания не работает не так и не сяк.

Проверочный код:

IDL:

Код: Выделить всё

   [uuid(FEAC2EA8-823C-4296-B095-2E4FD4F3E7F8), dual]
   interface IXXTest1: IDispatch
   {
      [id(20123)]
      void Test1();
   }
   
   [uuid(80A7B3A9-2E52-4cc4-9E3D-61F0E3608991), dual, nonextensible]
   interface IXXTest2: IDispatch
   {
      [id(20123)]
      void Test1();
   }

VB:

Код: Выделить всё

    Dim k As IXXTest1
    k.Test1
    k.Mujajajajajajajajajajaja ' Компилируется
   
    Dim j As IXXTest2
    j.Test1
    j.Mujajajajajajajajajajaja ' Не компилируется!!!

[ger_kar]

Проверочный код:

Проверил, работает, так как и писал Хакер. Странно, почему то когда я проверял работало совершенно по другому. Правда мой подход был отличным от подхода Хакера. Он объявил сразу два интерфейса, а я просто добавлял/убирал атрибут и делал перекомпиляцию TLB. Может быть что то где то кэшировалось, может я перекомпилировал забыв предварительно сохранить изменения, может еще что то. Но получается да, я лажанул . У меня поведение при изменении атрибута никак не менялось. Пойду дальше тестировать