[omniORB] Interface design best practice, as I'm tempted to use any

[Duncan Grisby]

On Fri, 2020-06-05 at 11:46 -0500, Jim Bell via omniORB-list wrote:

> I'm designing a new interface that will conceptually deal with system
> state events. A state changes and you send it around, or you query
> something for its states and it tells you their current values, with
> a single mechanism doing things like aggregation, logging and such.

[...]
> Address -- which system state
> Time occurred
> New value, whose type depends on the particular Address.
> The Address is complex:
> 
> Identifier (a numeric ID or enum would suffice)
> Parameter(s), whose type depends on the particular identifier.
> 
> The temptation is to use any for both the Address Parameter and State
> Event New Value.  But that bypasses type safety.

When I have built things like this, I've used an IDL union. That gives
you a bit more static type safety than using an Any, while still
allowing a lot of flexibility.

It sounds like you could use a union for the address parameters.
Whether the Event New Value part could be a union depends on whether
you can pin down the different types with a suitable parameter.

It slightly bends the rules of the CORBA specification, but you can
safely use an enum (or integer) as a union discriminator, and add still
new entries in later versions, as long as you are careful not to send
new values to old version consumers.

e.g. you can do something like this:


enum MessageType {
  MESSAGE_1,
  MESSAGE_2
};

union Message switch(MessageType) {
  case MESSAGE_1:
    SomeType message_1_val;

  case MESSAGE_2:
    AnotherType message_2_val;
};

interface Receiver {
  MessageType maxSupportedMessage();
  // What is the maximum message type supported by this server?

  void sendMessage(in Message msg);
};


Then later, you can add another message type to the end of the enum. As
long as clients follow the rules that they do not send a message with a
higher enum value that the one the server says it supports, it will not
matter if a new client talks to an old server. You must not change the
order of entries in the enum, because that would change the marshalled
form of the messages.

Whether this is better or worse than using Anys is a matter of
judgement. It is more type safe and more visible what is expected from
the IDL, but it probably involves a little more work than using Any.

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --