Python plugin

[Samuel A. Falvo II]

>>I tried com for many years without coming close to understanding it. If
>>M$ continues to have huge leverage it will continue to be arcane and for
>>wizards only!

I don't know why, but I keep missing the original messages.  I'm starting to
get annoyed with our newsserver... *sigh*

COM is exceptionally //easy// to understand.  If you can't understand it,
it's solely because you are deliberately making it more complicated than it
really is.

I'll be blunt:

	COM objects do not follow the traditional, "politically-correct"
	class-hierarchy object model that most other programming languages
	follow.

Once you get the idea that an "object" is something which belongs to a
class, and "is-a" something else, out of your mind, you can move on to the
next big revelation, which is a vastly more powerful concept anyway:

	An object is a thing.  It has an identity.  It can do stuff.

Note that nowhere does it indicate that it belongs to a class.  Nowhere does
it indicate that it exhibits an is-a relationship with another class (how
can it, if it doesn't belong to a class of objects)?

Let me give you a real-world example.  Your computer monitor has a viewing
surface on it; it could be an LCD screen, or it could be a CRT tube.  It
doesn't matter.  Likewise, your TV set also has a display surface on it.  It
follows that a TV "is a" monitor.  After all, it lets you see ("monitor")
things, no?

But doesn't a sheet of paper /also/ exhibit a viewing surface?  It too is an
object that exposes the same basic functionality as a computer monitor or TV
set -- you can SEE things on a sheet of paper.  Yet, a sheet of paper is not
a monitor.

Here, we have an example of an object which exhibits pretty much the same
functionality (interfaces) as a TV, yet is used for a radically different
purpose.

In terms of COM, we could define the following interfaces using some
hypothetical interface description language:

	interface IViewingSurface:
		def See( self ): returns None

Now, the paper object can define the See method to expose the same image
over and over again.  It's a completely static image.  Yet, our TV object
can define the See method to render a different image everytime it's called,
depending on what channel it's tuned to, and what frame of video is being
transmitted.

Now, in order to actually change the channels, we need another interface --
the knobs:

	interface ITVKnobs:
		def SetChannel( self, channel ): returns None
		def GetChannel( self ): returns channel
		def SetVolume( self, volume ): returns None
		def GetVolume( self ): returns volume

The TV object would implement the ITVKnobs interface, whereas our sheet of
paper wouldn't -- you cannot change the channel on a sheet of paper
(remember: we're dealing with a sheet of paper object, not a book object).
And even if we could, how could we change the volume of a sheet of paper?

COM eschews the concept that each object "belongs" to one or more classes
because, in reality, objects rarely do belong to a finite set of
classes.  It simply doesn't make sense to attempt to be academically correct
when, in the real world, it has little applicability.  (Aside: It is pretty
much a proven track record that real-world issues and academic solutions
rarely, if ever, meet in the middle.)

Instead, COM concentrates on the concept that an object just "does it" (to
steal an ad from Nike).  It is up to the object itself to determine which
interfaces it exposes.  It is merely the collection of interfaces it
supports that determines its type.  For example, we know that if we receive
an object that supports the IViewableSurface interface, we know that it's
some kind of viewable surface.  If it ALSO supports the ITVKnobs interface,
we know unambiguously that it is, indeed a TV.  Never mind whatever else it
supports -- the fact that it supports those two interfaces makes it a TV.
Period.  No questions asked.

Please don't take this the wrong way -- it's not meant as an offense.  But
if you get your mind out of the gutter for a bit, and realize that this
whole "object oriented" thang has been advocated pretty much by the academia
alone, you'll quickly realize why OO is the way it is: in order to save
time, students draw from prior art when writing their theses.  As a result,
entire WORLDS of alternative, yet perfectly valid, forms of object
orientation have gone unexplored.  Again, please don't take the above as an
offense.  I just don't know how else to express it.

>Keep in mind the fact that although working with COM may be simple (and
>Sam is the authority on this, since he has implemented a reasonably
>complete implementation, with a start at documentation), working with
>Windows involves more than COM -- you've gotta work out the whole
>API/framework classes.

Precisely.  In fact, the COM API is by far the simplest and most well
designed Windows API I'd ever seen.  Everything else is horribly written,
with inconsistent error handling techniques, poor nomenclature resulting in
similar-sounding API functions, but radically different jobs, and worse,
several functions, all with similar signatures, all of which do largely the
same thing -- a hallmark of very poor factorization.

And COM objects themselves are quite easy to work with.  What can be easier
than a table of function pointers?  Ever worked with the Berkeley DB
interface?  There's a perfect example of a COM-like object that *ISN'T* from
Microsoft, yet everybody and their grandmother hails Sleepycat for their
superior database API.

All COM _really_ does is give a standard layout to the first three function
table entries of each object's interface.  That's it!

>>Python at least allowed me in without a lot of exotic
>>verbiage.

Then I'd suspect you're a neophyte to object oriented technology.  Again, no
offense towards you.  But it seems that you're not well versed in object
oriented concepts, or your fresh out of, or still in, college.  The concept
behind COM is one of the easiest to understand concepts, addressing all the
complicated issues behind multiple inheritance and more, in a simple,
easy-to-read specification document.  A document which, by the way, is open
to the public.  No secret handshakes or high wizardry here.  In fact, I'll
even give you the URL to the COM specification, so you can read it yourself:

	http://msdn.microsoft.com/library/specs/S1D139.HTM

Or you can get a printable copy (Microsoft Word format) from:
	
	http://www.microsoft.com/com/resources/specs.asp

In fact, these are the documents I'm using to implement my GCOM package for
Linux and Dolphin.

Note that these documents describe the COM 0.9 specification.  This is the
last specification to be in the hands of Microsoft.  1.0 was donated to the
Distributed Computing Environment (DCE), thus making COM a commercially open
standard.

But you don't need DCE to get the latest spec, either.  Just browse
Microsoft's MSDN on-line library, and you'll get ALL the latest
specifications for the latest version of COM, including the interfaces used
for asynchronous, non-blocking method calls, transaction services,
MAPI/TAPI/DirectX, and more.  So starting with the 0.9 spec, and
incorporating the more modern APIs and COM objects documented in the other
on-line manuals will give you, pretty much, COM+ without ever having to
spend a dime on Windows 2000.

>>I'm not a whizz at COM, but Bill Tutt, Hark Hammond and the
>>other COMerati regularly throw up their hands at the complexity and
>>opacity of it all.

And you don't get this with CORBA?  Or with SOM?  Or with binaries written
that you don't have source code to?  I have experience with CORBA, and let
me tell you, it ain't pretty.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA