Re: GNOME & KOM/OP

[David Jeske <jeske home chat net>]

On Fri, Aug 07, 1998 at 11:12:39AM -0700, Miles Egan wrote:
> On Fri, 7 Aug 1998, Todd Graham Lewis wrote:
> 
> > for more info:
> > 
> > 	http://www.microsoft.com/oledev/
> 
> Somewhat ironically, this site is no longer maintained and redirects the
> reader to Microsoft's COM page.
> 
> I've done enough COM/Active-X/OLE coding to come to the conclusion that
> the design idea may not be bad, but it's implementation in windows is
> completely FUBAR.  Just try writing a multithreaded COM application,
> especially one involving IDispatch. 

The philosophy of COM (IMO) is quite good, and as you say, the
implementation on windows is quite bad. They recognized some key
traits which make COM able to gracefully handle compatibility and
backward compatibility.
  1) no inheritence
      - this makes all access to interfaces fine-grained. To contrast
        with a class based system, when someone uses a 'Windows' pointer
        you have to support every method all the way up the inheritence
        tree in order to make a compatible window, even though he probably
        dosn't use any of them. In COM, what you have to implement to be
        compatible is better isolated. 
  2) aggregation instead of subclassing for code-reuse
      - this allows lots of run-time object composition to occur. For
        example, you can write a 'matrix multiply' object which can
        be added on (sort of like a filter) to any object which exports the
        Matrix interface. This can be done at runtime, and if you so choose,
        it can be done automagically. That is, the Matrix coder never knew
        his object was going to be able to multiply.
  3) No fragile base class problems
      - both because all instance data is truly hidden (i.e. you can't
        access instance data which is not part of the same implementation
        as the code), and because object factories are used to create and
        compose objects, there are no fragile base class problems.
  4) No versioning is good versioning
      - being able to change the interface of an object after code out there
        is already linked to it has always been a careful balancing act.
        COM just admits that this dosn't make any sense. Once you publish
        an interface to the world, it can never change. This assures that
        you never break the ability for old programs to bind correctly.
        An object can support any number of interfaces, so if you want to
        be backward compatible, you just support the old and the new.
        More importantly, this allows you to avoid the legacy code problem
        to a great degree. Because of the robust binding of code to
        interfaces, you can throw out an old implementation, write the new
        one the way you want it, and then implement the old interface
        through the new interface. The COM object model make sure you get
        the binding right.. (no more hacking shlibs, etc, etc)

> I'm also not particularly impressed with the things Microsoft has done
> with OLE so far.  For example, opening a word file from within developer
> studio results in word hijacking devstudio - inserting it's window and
> menus into the devstudio shell.  This is slow and, to me, seems and
> awkward - a sort of frankenstein application. 

Agreed. NeXT did much better things with OLE type inter-application
communication. In NeXT apps tried to use less screen-space and make it
seamless for you to use windows from several apps in concert.

> It's also interesting to note that Microsoft itself is very actively
> downplaying both OLE and ActiveX these days, choosing instead to
> evangelize COM.  Interviews with MS executives on the subject have a
> surprisingly confessional tone.  All the windows developers I work with
> think of OLE as a confusing monstrosity and avoid learning anything more
> about it than is absoultely necessary.  The definite OLE book,
> Brockschmidt's _Inside OLE_ is widely regarded among the developers I know
> as one of the densest, most cryptic, and least pleasant to read of all of
> the MS press books.

This is not surprising. COM was invented by the OLE people. In fact,
OLE2 was synonomous with COM for a while. However, they have been
emphasizing COM as a generalized object model upon which all their
code is going to be based. OLE, ActiveX, and DirectX are all written
in COM now.

> All this is not to say that I think it's a bad idea to model GOM after
> OLE2.  I worries me a bit because I'm not convinced it's been that much of
> a success in windows and because I think there are a lot of pitfalls in
> its implementation.  At least we've got one bad example to avoid.

I think modeling GOM after COM's conceptual ideas is a great idea. I
wouldn't follow their implementation though. MS actually maintains
that COM is a 'binary standard', in that it defines the binary layout
of COM objects in memory. This has some advantages but just as many
disadvantages. They are moving away from this and providing a proper
'runtime' for COM in COM+, which is due out next year. 

Another problem with COM is that there is no native language syntax
for describing COM objects, so that you end up using tons of nasty
macros, and writing lots of code to implement it. They are also trying
to fix this by providing a native 'direct to COM+' syntax and compiler
with VC++ 6.0.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net