1 package org.omg.DynamicAny; 2 3 4 /** 5 * org/omg/DynamicAny/DynAny.java . 6 * Generated by the IDL-to-Java compiler (portable), version "3.2" 7 * from ../../../../src/share/classes/org/omg/DynamicAny/DynamicAny.idl 8 * Saturday, February 9, 2008 9:40:11 AM GMT 9 */ 10 11 12 /** 13 * Any values can be dynamically interpreted (traversed) and constructed through DynAny objects. 14 * A DynAny object is associated with a data value which corresponds to a copy of the value 15 * inserted into an any. 16 * <P>A DynAny object may be viewed as an ordered collection of component DynAnys. 17 * For DynAnys representing a basic type, such as long, or a type without components, 18 * such as an empty exception, the ordered collection of components is empty. 19 * Each DynAny object maintains the notion of a current position into its collection 20 * of component DynAnys. The current position is identified by an index value that runs 21 * from 0 to n-1, where n is the number of components. 22 * The special index value -1 indicates a current position that points nowhere. 23 * For values that cannot have a current position (such as an empty exception), 24 * the index value is fixed at -1. 25 * If a DynAny is initialized with a value that has components, the index is initialized to 0. 26 * After creation of an uninitialized DynAny (that is, a DynAny that has no value but a TypeCode 27 * that permits components), the current position depends on the type of value represented by 28 * the DynAny. (The current position is set to 0 or -1, depending on whether the new DynAny 29 * gets default values for its components.) 30 * <P>The iteration operations rewind, seek, and next can be used to change the current position 31 * and the current_component operation returns the component at the current position. 32 * The component_count operation returns the number of components of a DynAny. 33 * Collectively, these operations enable iteration over the components of a DynAny, for example, 34 * to (recursively) examine its contents. 35 * <P>A constructed DynAny object is a DynAny object associated with a constructed type. 36 * There is a different interface, inheriting from the DynAny interface, associated with 37 * each kind of constructed type in IDL (fixed, enum, struct, sequence, union, array, 38 * exception, and value type). 39 * <P>A constructed DynAny object exports operations that enable the creation of new DynAny objects, 40 * each of them associated with a component of the constructed data value. 41 * As an example, a DynStruct is associated with a struct value. This means that the DynStruct 42 * may be seen as owning an ordered collection of components, one for each structure member. 43 * The DynStruct object exports operations that enable the creation of new DynAny objects, 44 * each of them associated with a member of the struct. 45 * <P>If a DynAny object has been obtained from another (constructed) DynAny object, 46 * such as a DynAny representing a structure member that was created from a DynStruct, 47 * the member DynAny is logically contained in the DynStruct. 48 * Calling an insert or get operation leaves the current position unchanged. 49 * Destroying a top-level DynAny object (one that was not obtained as a component of another DynAny) 50 * also destroys any component DynAny objects obtained from it. 51 * Destroying a non-top level DynAny object does nothing. 52 * Invoking operations on a destroyed top-level DynAny or any of its descendants raises OBJECT_NOT_EXIST. 53 * If the programmer wants to destroy a DynAny object but still wants to manipulate some component 54 * of the data value associated with it, then he or she should first create a DynAny for the component 55 * and, after that, make a copy of the created DynAny object. 56 * <P>The behavior of DynAny objects has been defined in order to enable efficient implementations 57 * in terms of allocated memory space and speed of access. DynAny objects are intended to be used 58 * for traversing values extracted from anys or constructing values of anys at runtime. 59 * Their use for other purposes is not recommended. 60 * <P>Insert and get operations are necessary to handle basic DynAny objects 61 * but are also helpful to handle constructed DynAny objects. 62 * Inserting a basic data type value into a constructed DynAny object 63 * implies initializing the current component of the constructed data value 64 * associated with the DynAny object. For example, invoking insert_boolean on a 65 * DynStruct implies inserting a boolean data value at the current position 66 * of the associated struct data value. 67 * A type is consistent for inserting or extracting a value if its TypeCode is equivalent to 68 * the TypeCode contained in the DynAny or, if the DynAny has components, is equivalent to the TypeCode 69 * of the DynAny at the current position. 70 * <P>DynAny and DynAnyFactory objects are intended to be local to the process in which they are 71 * created and used. This means that references to DynAny and DynAnyFactory objects cannot be exported 72 * to other processes, or externalized with ORB.object_to_string(). 73 * If any attempt is made to do so, the offending operation will raise a MARSHAL system exception. 74 * Since their interfaces are specified in IDL, DynAny objects export operations defined in the standard 75 * org.omg.CORBA.Object interface. However, any attempt to invoke operations exported through the Object 76 * interface may raise the standard NO_IMPLEMENT exception. 77 * An attempt to use a DynAny object with the DII may raise the NO_IMPLEMENT exception. 78 */ 79 public interface DynAny extends DynAnyOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity 80 { 81 } // interface DynAny 82