COM/CORBA/DCOP (was: Hello people. I have some questions)

[Neil Hodgson]

Alex Martelli:
> "Neil Hodgson" <nhodgson at bigpond.net.au> wrote in message
> ...
> >    This is a nice interpretation of the COM spec (referenced later in
your
> > reply) but unfortunately it is an incorrect interpretation. Exception
here
>
> It's not an interpretation, it's the literal text of the COM specs.

   You are interpreting the text. Nothing is ever read with zero context.

> > is referring to C++ exceptions rather than SEH or crashing. No COM
server
>
> It specifically mentions that different languages have different
> concept of exceptions, so whence comes your *interpretation* that
> it is specific to C++ when it's explicitly saying the opposite?

   My interpretation of the context is that this is an explanation of how to
return error status. It says that error statuses should be returned by using
HRESULTs rather than throwing excptions because of the lack of portability
of exceptions between languages and environments.

   There is much source code and quite a few books available which implement
COM. Can you point to an example that implements COM in a way that is
compliant with your interpretation of this section?

> My COM server code always satisfies the letter of the spec (except
> when it has bugs -- but I don't introduce bugs deliberately:-).  SEH
> is normally handiest: rather than verirying pointer-correctness myself,
> let the hardware do it for me with a little help from the OS.  As
> usual, doing things right isn't that much harder than doing them
> sloppily or incorrectly.

   There are several problems with using SEH here - it adds to code bulk,
obfuscates the code and is not portable. There is also the question of how
far do you go? Just having one __try around the method that returns
E_POINTER is not as explanatory as producing a error info object that
pointed at the particular bad parameter but that would require lots of __try
blocks or some quite difficult decoding of the context where you receive the
exception.

> There is *NO* name which ensures the standard DISPID_NEWENUM will be
> returned by GetIDsOfNames (in the context of _collections_, only,
> the name "_NewEnum" is designated for that -- but it's to be marked
> as *restricted*, so it's *NOT* going to be returned by GetIDsOfNames
> in a compliant implementation!).

   The only explanation I can find for "restricted" is that it is not for
use by macro programmers or end users.

>  Microsoft has not designated any
> specific *names* duplicating the purposes of the various DISPID_NEWENUM,
> DISPID_VALUE (the default-property of an Automation object, if any),
> and so on, which it *has* reserved and designated.

   So you are prepared to not follow the letter of the specification for the
dispatch identifier? (Of course I can argue both sides :-) )

> In the abstract, you could make a case that a function must not
> waste effort trying to validate its preconditions -- that's not
> the function's job.  Meyers is as hot as usual in defending this
> stance in his PbC materials.

   I was expecting to be the one that first brought up PbC ;)

> What part of "strictly illegal" do you not understand?

   (eek! A catchphrase meme. I'd better watch out or I'll have to "get a
life")

   My interpretation of what this section is saying is
       How do we return status? [Goal]
       Can't use exceptions as they are not portable. [Explanation]
       Use status codes. [Rule]
       Most of the rest of the text is just additional explanation and
motivation.

   By interpreting this to an extent that would make a High Court judge
proud (one of ours invented an "implied right of political free speech" in
the Australian constitution because there was no explicit wording against
it) I think that I've achieved an understanding of how to implement COM
reasonably. All of the COM code I have read shares this interpretation.

   I no longer hang out on COM mailing lists. Is the current consensus in
agreement with you?

   Neil