[38] ANY
(Part of the CORBA FAQ, Copyright © 1996-99)

[38.1] WHAT IS AN ANY?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

An any is an IDL type that can represent “any” other IDL type. An any is the most abstract type. It requires runtime information to determine what type (and value) it really is.

[ Top | Bottom | Previous section | Next section ]

[38.2] HOW DOES AN ANY REPRESENT ITS RUNTIME TYPE?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

This is where typecodes come in. See the section on typecodes.

[ Top | Bottom | Previous section | Next section ]

[38.3] WHEN WOULD I USE AN ANY?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

An any comes in handy whenever you need to write IDL and do not know which CORBA type is appropriate.

This ambiguity rarely occurs in application IDL. Usually you know what you are dealing with and you use that type explicitly. Or, if you have an operation that may handle one of a couple of types (e.g., a float or a short), then a union is a possible type. Note, if you have an operation that is needs an abstract interface representation, then interface inheritance can be used. The ultimate base interface is CORBA::Object.

There are some cases, though, where an any is needed in application IDL. There are also some places where an any is used in system and service IDL. This is because the operation has to be generic enough to work with a broad range of types. For example, imagine the need to represent a generic property, which is a name-value pair. We have three choices:

1. Force all values to be strings, and then use a single struct. This approach has the advantage of being simple IDL. However, this potentially falls apart if it is difficult to represent the value as a string. Even if the representation is not a problem, the representation conversion is a hassle:

    struct Property
    {
      string name;
      string value;
    };

    interface Foo
    {
      Property getElement(in string key);
    };

1. Write a lot of different structs, one for each type of value. This approach has the advantage of explicit typing with no conversion. However, this falls apart if we have to represent a type that we don’t know of, e.g., a user-defined struct. Also this would lead to a lot of variants of the same operation, one that handled each kind of struct:

    struct FloatProperty
    {
      string name;
      float  value;
    };

    struct ShortProperty
    {
      string name;
      short  value;
    };

    //more and more

    interface Foo
    {
      FloatProperty getFloatElement(in string key);
      ShortProperty getShortElement(in string key);
    };

1. Use an any. This approach has the advantage of simple IDL. Also, it is completely expandable to all types, including user-defined types. Additionally, the application does not have to do conversions (this is essentially done in the marshalling/unmarshalling code). The disadvantage of this approach is the runtime typing — this impacts both the application code and the speed of the ORB communication:

    struct Property
    {
      string name;
      any    value;
    };

    interface Foo
    {
      Property getElement(in string key);
    };

[ Top | Bottom | Previous section | Next section ]

[38.4] OKAY, SO WHY NOT USE ANYS ALL THE TIME?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Sometimes the genericism of an any is appealing. But make sure you need this feature. The disadvantages of using an any include:

• There is no compile-time type information. This makes the application code harder to write, debug, maintain, etc.
• Communicating an any is relatively expensive for the ORB.

[ Top | Bottom | Previous section | Next section ]

[38.5] AN ANY SEEMS VERY DYNAMIC, SO WHAT’S A DYNAMIC ANY?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

A Dynamic Any (DynAny) is not an IDL type, like an any. A DynAny solves a technical glitch in the role of the IDL compiler. A DynAny provides an API to construct an any even when the application code does not have benefit of the IDL (really the IDL generated code) that defines the type of the any.

[ Top | Bottom | Previous section | Next section ]

 E-mail us