CORBA25 — Missing TypeCode identity

Steve's and my book contains a bit of code that pretty-prints a TypeCode.
(See page 704ff, in particular, 709-711.) No big deal – just write
a recursive function that does a depth-first traversal of a TypeCode tree
and prints things out, except for one thing: recursive types.

For recursive types, the code has to be careful not to get trapped in
infinite recursion. In essence, this means that the pretty-printer has to
remember which TypeCodes it has already seen and end the recursion if it gets
to a TypeCode that was printed previously. This is where we run into
problems because there is no legal way to do this:

• I cannot rely on the repository ID in the TypeCode to determine
  TypeCode identity because the repository ID for structs and
  unions is optional prior to GIOP 1.2, but recursion happens
  via structs and unions. (A GIOP 1.2 implementation may interoperate
  with a GIOP 1.0 or 1.1 implementation and still end up sending
  TypeCodes without repository IDs.)

• The code in the book uses is_equivalent() to determine whether
  it has seen a TypeCode previously. However, doing this is
  completely illegal (even though it happens to work with most
  ORBs) because:

• is_equivalent() does not provide object identity.

• TypeCode is a pseudo-object, and pseudo-objects do
  not inherit from CORBA object. This means that TypeCode
  doesn't even have an is_equivalent() operation that I
  could call.

So, as far as I can see, there is no compliant way to reliably and portably
determine TypeCode identity and, as a result, I can't ever reliably parse
a TypeCode...

I can see several solutions for this problem, all with different drawbacks:

1) Add an identity() operation of some kind to TypeCode.

An ORB that receives a TypeCode would have to make sure that
it generates a unique ID for each TypeCode. But that's not
all that easy to implement – in particular, if we have an
older TypeCode where all the optional bits are missing, we
can't reliably establish object identity for a TypeCode.
(Only structural comparison is possible.)

2) Add an identity() operation to TypeCode, but have the TypeCode's
identity generated at the sending end instead of the receiving
end.

Major drawbacks: the identity would have to large because it
needs to be globally unique (e.g. a UUID) and it would change
the marshaling of TypeCodes.

3) Add is_equivalent() and hash() operations to TypeCode.

This might break existing ORB implementations because a lot
of ORBs seem to inherit from Object for TypeCode and other PIDL
objects, even though they shouldn't.

4) Make PIDL objects implicitly inherit from CORBA::Object.

Note that making the repository ID mandatory is impossible because we
can't legislate for existing GIOP 1.0 or 1.1 implementations...

On a related note, we seem to have further problems with the idea that
PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
(for example, to CORBA::is_nil()). This really means that the C++ mapping
(and possible mappings for other languages) are completely in conflict
with the core spec...

My feeling is that option 4 is really the least-intrusive one. But I'm
not sure that I fully understand all the ramifications of making that change.

see above