[omniORB] simple question on general Corba

[Sveta Shasharina]

Duncan,  I make it work as you suggested and will also implement
the enum solution.

Hard to concentrate.  We have the radio on in the office.  What horror!

Thanks for your help.

Sveta

-----Original Message-----
From: owner-omniorb-list@uk.research.att.com
[mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of Duncan
Grisby
Sent: Tuesday, September 11, 2001 11:04 AM
To: sveta@txcorp.com
Cc: omni
Subject: Re: [omniORB] simple question on general Corba 


On Tuesday 11 September, "Sveta Shasharina" wrote:

> So, the signatures of the calls for accessors and modifiers
> are overloaded as I expected. (I derived it from looking 
> at the skeleton h-file.)  Although, one of the omni 
> correspondents (Carl) suggested that I should
> use get_name and set_name.  By the way, I was using orbacus
> for this exersize, not omniorb.  Is there a difference?

Carl was wrong. Attributes are mapped to two identically named
functions in C++. It doesn't matter which ORB you use. In the Python
mapping, they are mapped to _get_foo() and _set_foo().

> I understood Duncan's points about benefits of using struct
> versus intrerfaces with attributes.  The problem is that I
> do want inheritance, so I could use classes polymorphically.
> To illustrate what I need, I will give this in C++ mapping:

If you know all the "derived" types at the time you write the IDL, you
can use a union:

  enum UnitKind { UNIT_PARAM, UNIT_OPTION };

  union UnitValue switch (UnitKind) {
    case UNIT_PARAM:  double d_value;
    case UNIT_OPTION: long   int_value;
  };

  struct Unit {
    string    name;
    string    unit;
    string    operation;
    UnitValue value;
  };


If you don't know the types, an Any is the right thing to use.

Another option might be to use objects by value, but omniORB doesn't
support them yet.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --