From: Jason D. <ja...@in...> - 2001-12-03 17:39:47
|
> By a COM like version, I mean the use of HRESULT as > the return value for each function and each struct > has a pointer to a vtable for the first member with > the first three vtable entries being query, addref, > and release. Also, some encapsulation of memory > mangement would be needed so that IMalloc could > be plugged in later on. If you want the objects to be used from all versions of the VB family, you have to implement IDispatch. That means there's actually seven entries in the vtable you have to reserve (and implement). That's going to be the least of your problems, though. Automation-compatible interfaces have a slew of restrictions placed on them that you're going to have to hide behind macros in order to get an API that's usable by both C programmers and COM scripters. I've learned from experience that this is not what you want to do. I wrote an RDF parser in Standard C last year. One of my goals was to be able to use it from Automation-compliant environments (like VB and JScript). It was also important to me that "normal" C programmers (using Windows, Linux, or any other platform) could use it as well. So instead of re-inventing a small subset of COM that could compile on all platforms, I wrote the parser with C programmers in mind. The API looks like a fairly typical C API. If you want people to actually use libyaml, this is the approach you should take. Otherwise, somebody else will create their own implementation. For my VB friends, I created a wrapper (or facade) COM object. This handled all the conversions to and from BSTRs, VARIANTs, and many other COM-isms. It's API looks like your typical COM API. Sure, it's an extra layer that could have been avoided by judicious use of macros but since we're talking about VB, I can guarantee this layer will not be the bottleneck. And think about the people who will be helping maintain the libyaml source with you. I can bet that many if not most of them will be Unix hackers who won't even be able to compile and test the VB specific parts of the code. COM has already started dying a slow but sure death as it is. The next version of VB (VB.NET) is no longer COM-centric. Your COM objects can still be used but it's no longer the "native" API. The great thing about the whole .NET Framework, though, is that you can write your wrapper in any language supported by the runtime (as long as it can make native calls, of course) and then use that wrapper from any other .NET language. .NET does not use vtables the way that COM does so you _have_ to write a wrapper. But that's a good thing. Hope this helps, Jason. |