"Scott Egan" <scotte@tpg.com.aux> wrote:

> Actually, a com interface is a MS C++ compatible virtual pointer table. It is defilned that way to be completely simple to implement in MS C++ (et al). It is a binary standard for defining functions (methods) and not properties. COM requires that all interfaces derive from IUnknown; however, this is just a way of providing object life time control by reference counting.

Don't forget IUnknown::QueryInterface(), which is where most of the weirdness enters in :-)

> The IDispatch inteface is another layer on top of this, implementing a bunch of functions that allow 'late bound' applications to pass all functions calls (and property set/reads) through a single function as varaints - very ugly.

And slow. But it's how you get languages such as VB and JavaScript to talk to COM objects, and in many of those cases speed isn't the main issue.

> Does this make sence to anyone - does anyone care?

Yes, it was a good explanation. I think our interest here is whether supporting COM in D will inhibit functionality for non-COM applications. The line of thought that COM is a special case, but necessary for acceptance in the real world, makes the most sense to me. I like the idea of having a special way to indicate a COM interface, with special behavior limited to those kinds of declarations, and with Java-like behavior for standard D interfaces. In fact, if a D-style COM interface declaration had smart pointer functionality like _comptr_t<> or CComPtr<>, with reference counting management built in, and QueryInterface() calls via D's standard cast() keyword, that would be slick. Of course, there's probably issues with that which I haven't thought through (I'm certainly not a COM expert).

-- 
dave

Do you know that VB only uses IDispatch when its using the generic object type.

Its smart enough to use the actual vtbl for dual interfaces and can even use pure COM (ie no IDispatch) if the types are legal automation ones.

If you try hard you can get VB to directly call things like the DirectX COM APIs without a wrapper.

Scott

"Dave Sieber" <dsieber@spamnot.sbcglobal.net> wrote in message news:Xns94CB41CBD5908dsiebersbc@63.105.9.61...
> "Scott Egan" <scotte@tpg.com.aux> wrote:
>
> > Actually, a com interface is a MS C++ compatible virtual pointer table. It is defilned that way to be completely simple to implement in MS C++ (et al). It is a binary standard for defining functions (methods) and not properties. COM requires that all interfaces derive from IUnknown; however, this is just a way of providing object life time control by reference counting.
>
> Don't forget IUnknown::QueryInterface(), which is where most of the
> weirdness enters in :-)
>
> > The IDispatch inteface is another layer on top of this, implementing a bunch of functions that allow 'late bound' applications to pass all functions calls (and property set/reads) through a single function as varaints - very ugly.
>
> And slow. But it's how you get languages such as VB and JavaScript to talk to COM objects, and in many of those cases speed isn't the main issue.
>
> > Does this make sence to anyone - does anyone care?
>
> Yes, it was a good explanation. I think our interest here is whether supporting COM in D will inhibit functionality for non-COM applications. The line of thought that COM is a special case, but necessary for acceptance in the real world, makes the most sense to me. I like the idea of having a special way to indicate a COM interface, with special behavior limited to those kinds of declarations, and with Java-like behavior for standard D interfaces. In fact, if a D-style COM interface declaration had smart pointer functionality like _comptr_t<> or CComPtr<>, with reference counting management built in, and QueryInterface() calls via D's standard cast() keyword, that would be slick. Of course, there's probably issues with that which I haven't thought through (I'm certainly not a COM
expert).
>
> -- 
> dave

"Scott Egan" <scotte@tpg.com.aux> wrote:

> Do you know that VB only uses IDispatch when its using the generic object type.
> 
> Its smart enough to use the actual vtbl for dual interfaces and can even use pure COM (ie no IDispatch) if the types are legal automation ones.
> 
> If you try hard you can get VB to directly call things like the DirectX COM APIs without a wrapper.

No, I didn't know that!  But I've done only very little VB. I guess this would be possible when you declare the object type up-front (when you import the type library via References)?

I once tried to get VB6 to use the DirectShow API for video capture, but gave up on it quickly -- probably didn't understand VB well enough at the time.

This makes me wonder, though: would it make any sense for D's "import" keyword to work like MS's "import" in C++, where it can import a COM type library? Or maybe a different keyword, like "com_import". And then D could generate D-style smart pointer interfaces for the library? (just thinking out loud, maybe it makes no sense...). If it worked, though, it would make COM (client) programming in D very clean.

-- 
dave