Issues for Object by Value RTF Discussion Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1055: Can value type inherit from Value Box type Jira Issue CORBA23-96
Issue 1064: Section 5.5 Interface repository (01) Jira Issue CORBA23-97
Issue 1065: Section 5.5 Interface repository (02) Jira Issue CORBA23-98
Issue 1140: Which TypeCode operations apply to Value and ValueBox? Jira Issue CORBA23-99
Issue 1250: "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] Jira Issue CORBA23-235
Issue 1251: "Safe" keyword identifier issue Jira Issue CORBA23-100
Issue 1252: Can Value type inherit from Value Box type? Jira Issue CORBA23-101
Issue 1253: New lexical type - Keyword Identifie Jira Issue CORBA23-102
Issue 1254: Grammar rule issue Jira Issue CORBA23-236
Issue 1255: Section 5.3.3: can value inherit from a boxed value? Jira Issue CORBA23-103
Issue 1256: p.6.68 boxed values of complex types map to same type Jira Issue CORBA23-104
Issue 1257: Value type ansd Value Box"s single data member name Jira Issue CORBA23-105
Issue 1258: describe_value() operation issue Jira Issue CORBA23-106
Issue 1260: Missing member_kind and member_tc Jira Issue CORBA23-107
Issue 1261: Type code issue Jira Issue CORBA23-108
Issue 1262: Clarify the hash code algorithm Jira Issue CORBA23-109
Issue 1263: Section 5.6.2 Repository Id Jira Issue CORBA23-110
Issue 1264: Repository Id (02) Jira Issue CORBA23-111
Issue 1265: Repository Id (03) Jira Issue CORBA23-112
Issue 1266: Section 5.6.3 Hashing Algorythm Jira Issue CORBA23-113
Issue 1267: Semantics of computing the hash code.. Jira Issue CORBA23-114
Issue 1268: Concrete value class Jira Issue CORBA23-115
Issue 1269: Section 7.3.5 ValueBase and Reference Counting Jira Issue CORBA23-116
Issue 1270: Section 7.3.6 Reference Counting Mix-in Classes Jira Issue CORBA23-117
Issue 1271: Section 7 C++ Language mapping Jira Issue CORBA23-118
Issue 1272: Java mapping example and C++ mapping example Jira Issue CORBA23-119
Issue 1273: Section 7.3.10 Value Factories Jira Issue CORBA23-120
Issue 1274: Why is ValueBase a value and not a native type? Jira Issue CORBA23-121
Issue 1275: Can an instance of C be passed by value to an operation that expects an A? Jira Issue CORBA23-122
Issue 1277: Editorial page 8-107 Jira Issue CORBA23-123
Issue 1279: p 5-24, first paragraph of 5.3.1.3 Jira Issue CORBA23-124
Issue 1280: Suggested changes (to section 5.4.1 of orbos/98-01-18) are Jira Issue CORBA23-125
Issue 1281: Which exceptions should be raised? Jira Issue CORBA23-237
Issue 1282: Editorial: p 5-50 Jira Issue CORBA23-126
Issue 1283: p 5-50 2nd paragraph of 5.6.2.1 Jira Issue CORBA23-127
Issue 1284: Can public modifier be applied to value operations? Jira Issue CORBA23-128
Issue 1285: Clarify semantics Jira Issue CORBA23-238
Issue 1286: Reconcile RMI/IIOP upcall and helper class Jira Issue CORBA23-129
Issue 1310: Keyword identifiers (01) Jira Issue CORBA23-130
Issue 1311: Keyword identifiers (02) Jira Issue CORBA23-131
Issue 1312: Keyword Identifiers(03) Jira Issue CORBA23-132
Issue 1313: Keyword identifiers (04) Jira Issue CORBA23-133
Issue 1321: public static org.omg.CORBA.ValueDef get_value_def(); Jira Issue CORBA23-239
Issue 1352: No portable way to obtain list of type safe repository IDs Jira Issue CORBA23-134
Issue 1353: Marshaling engine issue Jira Issue CORBA23-135
Issue 1380: Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private Jira Issue CORBA23-136
Issue 1382: Narrowing from abstract interfaces Jira Issue CORBA23-137
Issue 1419: "in". "out", and "inout" modifiers on value operation parameters Jira Issue CORBA23-138
Issue 1420: Typo on page 8-107 of OBV specification Jira Issue CORBA23-139
Issue 1421: Can "public" mofifier be applied to value operations? Jira Issue CORBA23-140
Issue 1522: OBV "chunking" Jira Issue CORBA23-141
Issue 1523: CDR Streams Jira Issue CORBA23-142
Issue 1526: Problem with C++ language mapping for OBV Jira Issue CORBA23-240
Issue 1527: TypeCodes defined in section 5.8.2 Jira Issue CORBA23-143
Issue 1528: ValueMemberSeq: What is to be done with the RepositoryID parameter? Jira Issue CORBA23-144
Issue 1529: DynAny::get_value collision Jira Issue CORBA23-241
Issue 1539: OBV C++ problem with "supports" Jira Issue CORBA23-145
Issue 1614: OBV spec inefficient for dending large number of small objects Jira Issue CORBA23-146
Issue 1615: Some explicit semantics seem to be missing in section5.8.6 Jira Issue CORBA23-147
Issue 1624: Forward declaration of value boxes Jira Issue CORBA23-148
Issue 1625: TypeCodes for values Jira Issue CORBA23-149
Issue 1650: Boxed values need extension to write_Value call Jira Issue CORBA23-150
Issue 1654: Default constructor for Java values Jira Issue CORBA23-151
Issue 1673: Custom marshalling support for IDL fixed type Jira Issue CORBA23-152
Issue 1674: C++ boxed value member clashes Jira Issue CORBA23-153
Issue 1676: OBV TypeCode parameters wrong Jira Issue CORBA23-154
Issue 1685: OBV TypeCode problems Jira Issue CORBA23-243
Issue 1697: P 5-44: use of base type Jira Issue CORBA23-155
Issue 1699: Abstract Interface issue (write_Abstract/read_Abstract)(01) Jira Issue CORBA23-156
Issue 1719: No typecodes for abstract interfaces Jira Issue CORBA23-157
Issue 1720: Abstract Interface issue (02) Jira Issue CORBA23-245
Issue 1726: TypeCode complexity for value types Jira Issue CORBA23-158
Issue 1727: Module separator within repository IDs Jira Issue CORBA23-242
Issue 1748: Memory Management for Value Factories Unspecified Jira Issue CORBA23-159
Issue 1771: CodeBase interface uses undefined type Jira Issue CORBA23-160
Issue 1782: New OBV "supports" keyword conflicts with CosLifeCycle Jira Issue CORBA23-246
Issue 1816: OBV init Jira Issue CORBA23-161
Issue 1817: Status of hashed repository IDs Jira Issue CORBA23-162
Issue 1932: "Tool" issue for IDL compilers too complex Jira Issue CORBA23-163
Issue 1934: ValueHelper Interface issue Jira Issue CORBA23-164

Issue 1055: Can value type inherit from Value Box type (obv-rtf)

Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is   described as been syntactic sugar for a Value type)? If so, what is the   implicit name of the Value Box"s single data member?    

Summary: 1)  ValueDefSeq is used in a couple of places but is never defined. A typedef   for it is missing.    

Summary: 2)  Attribute "name" in interface ValueMemberDef clashes with attribute "name"   inherited from Contained. A different name should be used, something like   "value_member_name"    

Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply   to Value and ValueBox types. For example, are id(), name(), member_name(),   member_count(), member_type(), etc. valid for Value and ValueBox or should they   raise BadKind exception?      I don"t see why they should not be valid. Normative text should be added in   CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in   the IDL should also be updated.    

Summary: I"ve come across another small glitch in the orbos/98-01-18   "Objects by Value" spec. This is in section 5.4.1 "Syntax", for the grammar rule:          <value_inheritance_spec> ::= ":" [ <safe_token ] <scoped_name>              { "," <scoped_name> }*              [ <supports_token> <scoped_name> { "," <scoped_name> }* ]       As the rule (and the rules referring to this rule) are written now, a value   inheritance spec is either optional, or if specified, MUST begin with an    inheritance relation to another value type (e.g. : value foo2: foo1 { ... }).    

Summary: Above rules seem to imply that the   "safe" keyword identifier can only occur before the first scoped name in the   <value_parent_spec>, whereas I think the actual intent is that it can only    occur before a non-abstract value type, of which there is at most one in the   list, although it need not be the first. Since this can"t be expressed in the   rules exactly, I would simply amend the rule to be:             <value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>                     { "," [ <safe_token> ] <scoped_name> }*       and simply express the semantic restriction in the text. There already is a   brief mention of the semantics of the "safe" keyword in section 5.3.2.5    "Substitutability Issues". Perhaps another sentence or two would help clarify   the intended usage.    

Summary: Can a Value type inherit from a Value Box type (the Value Box is described   as been syntactic sugar for a Value type)?    

 received issue

Summary:  Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that   "new keyword identifiers should only be added such that the resulting grammar is   still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for   the newly introduced keyword identifiers in many cases. 

Summary: The new grammar rule:           <state_member> ::= <public_token> <type_spec> <declarators> ";"                       | <type_spec> <declarators> ";"   seems to open up another large hole for making the grammar non-LALR(1), which may    or may not have been intentional. This becomes clear as you work your way back    through the set of grammar rules. For example, according to the way I read the rules,   the following is legal "new" IDL:    

Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a   boxed value ? If yes, the Java mapping of boxed values of type    string, sequence and arrays should be changed because String   and arrays can"t be extended in Java.    

Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map   all to the same type (i.e., as for typedefs, the value"s name appears   only in holder/helper classes), and that each boxed value of "basic" type   maps to its individual class. Instead, boxed values of basic types   could map to the corresponding java.lang.* class, e.g.    java.lang.Integer, java.lang.Short, etc. An issue with this approach    is that java.lang.Short and java.lang.Byte are not defined in JDK   1.0.2. I doubt however this JDK is still much in use; for its users,   short and octet could optionally map to e.g. CORBA.ShortValue and   CORBA.ByteValue (inspired from CORBA::StringValue).       

Summary: If a value type can inherit from a Boxed Value then what is the implicit name of   the Value Box"s single data member?    

 received issue

Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef   which returns a FullValueDescription structure.  Is there supposed to be another   operation which returns the shorter ValueDescription structure?     

Summary: Missing member_kind and member_tc    

Summary: TypeCodes:         - It is not clear whether the IDL compiler has to generate        a TypeCode object for each Value type.     

Summary: Clarify the hash code algorithm    

 closed issue

Summary: It is not clear whether the #pragma prefix is still part        of the repository Id. I think it should be.    

 received issue

Summary: Why is the 64 bit hash code at the end of the string and        not at the beginning ? This can speed up the comparison        when two repository Ids are different.    

Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming       policy?    

 received issue

Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)         - It is not clear whether the hash value is translated        into ascii or not.         - I assume the result is a long long:      	long long hash = sha[1] << 32 + sha[0]    

Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)       

 received issue

Summary: I have an important issue concerning the C++ mapping and the fact   that application developers need to define/implement the concrete   value class.    

Summary:    - What is the return type of "_add_ref" and "_remove_ref"        (defaults to "int", but what is the semantic of the result value)        => propose to change to "void"       

Summary: The default ref-counting classes are said to be "fully concrete".        Is this really necessary?        What is the semantic of "_copy_value" for the ref-counting class?        => suggest that "_copy_value" MUST NOT be implemented           (It is implemented by "_copy_value" of the real value type)    

 delete "must be concrete". Accepted into CORBA 2.3

Summary: According to the object-by-value C++ mapping, the value type that is     not boxed results in an abstract C++ class. Basically, the reference     counting methods are not provided (abstract). It is the responsibility of     application developer to define/implement a concrete class. Althought     this can be done, there are some issues:    

 no action, changed suggested would make c++ mapping consistent

Summary: In the Java mapping example on page 6-64 the operations are mapped to       public operations of the Java class. However in the C++ mapping example on page        7-95, the operations are mapped to protected pure virtual functions of the    	generated C++ class.    

Summary:  Semantic of register_value_factory is not clear        What do applications should expect if a factory is already        registered for a given repositoryId?           The operation returns the previous factory. But it is not        clear whether it is overriden or not.         - When should register_factory be called ?        I assume that this is after the ORB is initialized (since we        need a pointer to the ORB). This means that initialization        of "Component Libraries" is not trivial.    

Summary: What is the rationale for making ValueBase a value and not a native type?       It seems strange to me that a ValueBase "value" maps to java.io.serializable       in Java. Isn"t that what native was invented for?       

Summary:  Given:                  abstract interface A {};               interface B : A {};               value C : supports B {};                                                                                                                                                       Can an instance of C be passed by value to an operation that expects an A?    

Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and       value Currency should support Describable.    

 received issue

Summary: p 5-24, first paragraph of 5.3.1.3:   The implementation of operations may be remote if the value also   supports CORBA.Object.   typo p 5-30, last line of 5.3.2.6: may BE defined    

Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:        1. Remove the ``;"" from the end of the definition of <value>.  (It"s        in the modified <definition>.)        2. Remove [ <supports_token> <scoped_name> { ``,"" <scoped_name> }* ]        from the <value_inheritance_spec> non-terminal move it to a new        non-terminal, <value_supports_spec>.        3. Change the definitions of <value_abs_dcl> and <value_header>,         replacing [ <value_inheritance_spec> ] by [ <value_inheritance        _spec ] [ <value_supports_spec> ].    

Summary: Clarify which exception should be raised when no local class is   available to support an incoming value:   p 5-29, item 3 says it should be NO_IMPLEMENT   p 5-34, 3rd paragraph says it should be MARSHAL   p 5-34, last paragraph says it should be BAD_PARAM   p 6-67, last item says it should be MARSHAL   p 7-93, first paragraph of 7.3.10.2 says it should be MARSHAL    

Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...    

 closed issue

Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing   ORBs, version inconsistencies between, eg, structs, may already corrupt   memory. The difference now is that preservation of values sharing   could make matters worse. It would be great to have this issue better   explained.    

Summary: 1) Can the "public" modifier be applied to value operations? What is the default?    

 closed issue

Summary:  

Summary: Reconcile RMI/IIOP upcall and helper class    

 closed issue

Summary:    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced   the concept of "keyword identifiers" in an effort to avoid breaking   existing IDL specifications.   1) First and foremost, the addition of keyword identifiers changes   the IDL grammar into a context-sensitive grammar, which are known to   be notoriously difficult to parse. 

Summary:    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced   the concept of "keyword identifiers" in an effort to avoid breaking   existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:      interface ValueBase {};   struct S {       ValueBase v;   };      This is ambiguous because the compiler cannot know whether the type   of struct member "v" refers to the ValueBase interface or the   ValueBase keyword identifier.       

Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced   the concept of "keyword identifiers" in an effort to avoid breaking   existing IDL specifications. It specifies that a keyword identifier   is a word that is treated as a keyword only when used in a keyword   context, and is otherwise treated as a regular identifier.   3) It allows IDL specifications that, while not unparseable, are   highly ambiguous, especially to a human reader. For example, Jeff   recently posted answers on how the following is to be parsed, but   there is no way that someone reading the OBV spec would be able to   figure out the rules he gave:      interface public { ... };   interface custom { ... };   value safe { ... };      value foo : safe { ... };        // Is this legal or an error?   value foo2 : safe safe { ... };  // What about this?   value foo3 {       public x;         // Is this legal or an error?       public public y;  // What about this?       custom value();   // Is this a valid operation or a syntax error?   };      While all of these constructs can all be parsed using the appropriate   number of look-ahead tokens (by the way, the grammar is *not* LALR(1)   as the OBV Spec suggests), it is hard to read and even harder to   parse correctly. Many IDL compilers still fail to properly implement   the name lookup rules in the existing CORBA specification, and adding   keyword identifiers will only make that situation much worse.       

Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced   the concept of "keyword identifiers" in an effort to avoid breaking   existing IDL specifications. It specifies that a keyword identifier   is a word that is treated as a keyword only when used in a keyword   context, and is otherwise treated as a regular identifier.   4) Finally, the keyword identifier approach gives the impression that   IDL extensions can be made at no cost, which is simply not true.    

Summary: On p. 6-63 of orbos/98-01-18, the get_value_def() method is defined in   the helper class as:      public static org.omg.CORBA.ValueDef  get_value_def();      Currently, there is no portable way to implement this method for all   vendor ORB"s.  One suggestion is to pass an ORB implementation instance   as parameter:      get_value_def(org.omg.CORBA.ORB orb);      and then add a method to the ORB class such as:      get_value_def(String idl_name);      Thus a portable implementation could be      public static org.omg.CORBA.ValueDef get_value_def(org.omg.CORBA.ORB   orb) {     return  orb.get_value_def(id());   }       

Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real    type, going up (the derivation hierarchy) to, and including if  appropriate the formal type".  Currently, there is no portable way to obtain the list of type safe repository ID"s    from within the marshaling engine in order to be marshaled on-the-wire properly.     

Summary: Using the idl defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as it"s formal parameter.  Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it    does not know how many safe repository id"s it needs to marshal.     

 received issue

Summary: Section 5.3.1.2 says that non-public data members should be mapped   so that "the private part of the state is only accessible to the   implementation code and the marshaling routines."      Section 6.3.1 says that non-public data members are mapped to   private instance variables.      The problem is that the Java marshaling routines are in the Helper   class, which cannot see private instance variables in the value class.      The proposed solution is to modify the Java mapping to map the default   IDL state to the default (package visibility) Java state instead of   private.    

Summary: It has been pointed out to me that we have no way of narrowing   from abstract interfaces to non-abstract interfaces and value   classes.  In Java, the helper"s narrow method has a signature of    org.omg.CORBA.Object, so it cannot take an abstract interface   type.  In C++, the generated classes for abstract interfaces   have an _narrow method with the right signature (taking an   AbstractBase_ptr), but generated classes for values and regular   interfaces don"t have such a method.  It seems like we would    need to add overloaded narrow methods in all these places to   make this work as envisaged in (for example) numbered paragraph   3 of section 8.3.    

Summary: The "in", "out", and "inout" modifiers on value operation parameters  are   effectively comments. This is the case as a value maps to a language    pointer or reference. When it is passed in a local interface    there is no way to guarantee "in" or "out" semantics; it is passed by    reference which essentially has "inout" semantics.      These semantics should be explicitly stated.    

Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from    Describable and value Currency should support Describable.    

 received issue

Summary: Can the "public" modifier be applied to value operations? What is the default?    In the Java mapping example on page 6-64 the operations are mapped to    public operations of the Java class. However in the C++ mapping example on page    7-95, the operations are mapped to protected pure virtual functions of the generated    C++ class.    

  No. public/private does not apply to operations. See revised language mapping chapters for correct

Summary: The OBV spec adds the notion of "chunking" because it claims that "it is   anticipated that value types may be rather large, particularly when a graph   is being transmitted. Hence the encoding supports the breaking up of the   serialization into an arbitrary number of "chunks" in order to facilitate   incremental processing." (orbos/98-01-18, page 5-55)      This "feature" should be removed from the spec, since it is the job of the   underlying transport to handle this issue. GIOP already provides   fragmentation, allowing transports to handle large parameters efficiently   -- why should we build yet another fragmentation solution on top of it?    

Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for   custom marshaling. The names of these types should not contain "CDR" since   there is nothing that prevents them from being implemented to use a data   representation other than CDR.    

 see revised chapter

Summary: 1.  The following IDL cannot be translated into C++ code by an IDL   compiler for a C++ environment that does not support namespaces:      // IDL   module M {       struct S {   	boolean	b;       };          interface I {   	void op(in S arg);       };          value V supports A {       };   };      The reason for this is that module M maps to a C++ class when namespaces   are not available, and you end up with the following definition loop:          POA_M::I must be defined before M::V, since M::V inherits from it       M must be defined before POA_M, because POA_M::I depends on M::S       but defining M also defines M::V    

Summary: 1) The fill_in_recursive_sequence_tc method is intended to act      upon an existing "tk_value" TypeCode.  The signature indicates      that it should return a TypeCode pointer.         What TypeCode is supposed to be returned ?      If the signature is in error, the specification should      be corrected -- if not, the specification requires      some additional explanation as to which TypeCode      needs to be returned.    

Summary: 2) In addition to the ValueMemberSeq, the input parameters to       fill_in_recursive_sequence_tc include the target TypeCode      pointer, and the RepositoryId.         What is to be done with the RepositoryId parameter ?      Is the method supposed to update the Id as well ?      If that is the case, is it an optional/required parameter ?    

Summary: OBV specifies a DynAny::get_value operation to retrieve a value from a   DynAny, but this operation breaks the existing DynFixed::get_value   operation. I suggest renaming the DynAny::get_value to avoid the collision   (gee, if we didn"t use "value" as one of those funny keyword identifiers,   this wouldn"t be a problem).    

 rename methods to get_val. Accepted for CORBA 2.3

Summary: The OBV spec allows a value to support multiple interfaces. In C++, such   values   are specified to derive from the POA skeletons generated from those   interfaces.   This presents a potentially intractable problem: skeletons are not designed to   be inherited together with skeletons for other interfaces because servants do   not support multiple interfaces. (The Multiple Interface RFP isn"t finished   yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)   explicitly says    

Summary: One of the common patterns used in IDL specifications is to pass a   sequence of a data type in order to cut down on network round trips.    The current OBV spec (orbos/98-01-01) even suggests sending a graph of   objects and optimizing for the case where the same object occurs   multiple times in the graph (which I assume will normally be a small   number of the total objects).  The spec seems to be inefficient for   sending a large number of small objects though.  I have looked at the   errata before and don"t recall any relavent changes but know the RTF are   considering some now.    

Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not   describe the semantics behind them.  Some of the semantics are referred   to in earlier section and intuitive for an outsider with a little CORBA   experience.  Some of the the explicit semantics seem to be missing   altogether (e.g. the "+" in <end_tag>+).  It would be useful if the   descriptions explicitly used the names within the BNF grammar or   explicit specifications for each name in the grammar was given.                   

Summary: It is not clear from the spec whether or not value boxes can be    forward declared, and used recursively.  For example,          value v;       struct s {           long s0;           v next;       };       value v s;      If value boxes are indeed syntactic sugar, the answer should be yes.   That brings the next question: Does this mean that one can call   create_box_value_tc(), supplying NULL for the original_type, and   then later on fill in the member typecode via fill_in_recursive_tc,   supplying a ValueMemberSeq of length 1?    

Summary: The spec does not contain a clear definition of how TypeCodes for   values and value boxes are constructed.  There is something about   this in section 5.6.3, but this seems to describe a variant of the   algorithm rather than the algorithm itself.  Section 5.9.7 needs to   be expanded to describe this in at least as much detail as the   description of the encoding of recursive sequence TypeCodes in the   current CORBA spec.       

Summary: There"s a problem with the mapping to Java for boxed IDL values   for non-primitive Java types, for example, a boxed string or a   boxed sequence.  The currently specified write_Value call doesn"t   allow these to be marshalled correctly.    

Summary: The OBV spec is not very clear about whether the Java class   generated for an IDL value has a default (no-argument) constructor.      A no-argument constructor is needed so that the Helper class   can construct a value when demarshalling.  However, it should be   package-private in order to limit its visbility to the Helper   class and not expose it to client code.  This is also true for   state fields declared as private in the IDL value type (which the   spec currently states are mapped to private in Java).       

Summary: The custom marshalling streams CDRInputStream and CDROutputStream   don"t support the IDL fixed type.  I propose adding the following   type definition and methods:        typedef sequence<fixed> FixedSeq;        abstract value CDROutputStream {         ...         void write_fixed (in fixed value);         void write_fixed_array (in FixedSeq seq,                                 in unsigned long offset,                                  in unsigned long length);     };        abstract value CDRInputStream {         ...         fixed read_fixed ();         void read_fixed_array (inout FixedSeq seq,                                in unsigned long offset,                                 in unsigned long length);     };    

Summary: For boxed values that are structs, unions, or other constructed types with   member accessor and modifier functions, their member functions such as   value(), boxed_in(), boxed_inout(), etc. may potentially clash with the   names of those accessor and modifier functions.      Solution: make the names of such special member functions start with an   underscore, e.g., _value(), _boxed_in().    

Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both   tk_value and tk_value_box start with a string which is the type"s   repository ID. Why? For everything except tk_interface, the repository ID   is not visible as a parameter. I believe these parameter lists should not   include repository IDs to make them consistent with the others.      I assume that the {member_name, TypeCode} pairs in the tk_value parameter   list should appear in the order of declaration of the members in the   valuetype. This is not stated anywhere.      The visibility of each member should be added to the tk_value parameter   list. Each entry in the list should contain {member_name, TypeCode, short}   where the short refers to the Visibility of the member.      The parameter list for tk_value should probably have an additional   parameter which is the TypeCode of the concrete valuetype base, if any.       

Summary: For valuetypes that inherit from concrete valuetypes, the   ORB::create_value_tc operation is insufficient. In particular, it does not   allow the TypeCode for the base valuetype to be supplied. This means that   if a valuetype with a concrete base valuetype is passed in an Any to a   process that has no compile-time information concerning that valuetype, the   receiving process will be unable to marshal it. Having the RepositoryId of   the concrete base in the TypeCode does not solve the problem because the   two processes might not have an Interface Repository (IFR) in common, or   the concrete base RepositoryId may not be in the IFR known to the receiving   process. Also, never in CORBA should unmarshaling require lookups in the   IFR (this in fact should be an absolute ORB Core rule).      Proposal: change create_value_tc to      TypeCode create_value_tc(       in RepositoryId id,       in Identifier       name,       in boolean        is_custom,       in TypeCode     concrete_base,       in ValueMembersSeq members   );      If the valuetype has no concrete valuetype base, the concrete_base argument   shall be a nil TypeCode reference.       

Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type.  (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind.  However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value.  This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this.  The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase.  An alternate could be to not go the PrimitiveDef route and use a different approach.  Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase.  This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface).  This is less likely though because create_ValueBase would need to return a type.  We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named.  We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.    

 closed issue

Summary: 1. There are no write_Abstract and read_Abstract methods on       DataInputCtream and DataInputStream.  This looks like an oversight      to me.    

Summary: There are no typecodes for abstract interfaces.  Does this mean      that abstract interfaces cannot be members of structs, unions,      or values?  If so, I think this is a problem and we should add      typecodes for abstract interfaces.    

Summary: If we accept 2 above, we may want to revisit the following:      -- 8.8.2, page 8-104,  bullet 4:       "Inserting an abstract interface reference into a CORBA::Any      operates polymorphically. Either the object reference or value to      which the abstract interface reference refers is what actually gets       inserted into the Any. This is because there is no TypeCode for      abstract interfaces. Since abstract interfaces can not be inserted into      an Any, there is no need for abstract interface extraction operators."    

Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a   potentially recursive constructed type that involves ValueMembers.   The "tk_value" TypeCode defines the entire complexity of the types   within the Value.        It is our understanding that when the ORB code that handles "Anys" for   C++ detects a tk_value TypeCode and needs to encode/decode the associated   Value object -- (e.g., for Any::replace(TypeCode, void *) -- it will   need to invoke a method on that object that understands the object    instance data and the associated state information.  Further    examination of the TypeCode complexity will not be necessary by the   Any implementation, since this code would not have knowledge of or    ability to set the state information within the Value object itself.      The reason why the layout of the state information within a value   cannot be known by external code is that virtual inheritance of    abstract values and/or abstract interfaces makes it impossible to    calculate the offsets of the data members in a compiler   independent manner.       

Summary: The module separator within "IDL: style" repository IDs is a "/".   The module separator within "H: style" repository IDs is a "::".   Was this difference intentional?  If so, why?  It seems confusing   to treat scoped names differently in the two kinds of IDs.    

 see revised chapters

Summary: There are no rules governing how to free value factories in C++.   Specifically, the ORB does not know what to do with the value factory at   shutdown, and applications do not know what to do with the factory   returned by register_value_factory.  Directly deleting the factories may   be hazardous (e.g. if they are shared across multiple valuetypes or even   multiple ORBs), and leaving them around may introduce memory leaks.    

Summary: The definition for interface CodeBase in module SendingContext   has a method      CORBA::InterfaceRepository get_ir();      There is no type CORBA::InterfaceRepository.  I believe this was   intended to say      CORBA::Repository get_ir();       

:Repository get_ir(); 

Summary: The new OBV keyword "supports" collides with the operation "supports"   defined in CosLifeCycle::GenericFactory.       

Summary: The OBV spec introduces the concept of initializers, which maps   cleanly only to languages that support overloaded constructors.         Other languages, such as C, would typically offer functions to provide   inialization of values. Since initializers are not named, an intuitive   mapping is hard to find.    

Summary: The OBV spec orbos/98-01-18 introduces a new repository ID   mechanism. It says in 5.6.2.1      >> We don"t recommand the classic id format "IDL:" <scoped name> ":"   >> <major> "." <minor> because it is not "foolproof" enough. (It is of   >> course allowable to use this format, since the CORE specification   >> does not mandate any particular form.)      The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33   specifies      >> A definition is globally identified by an OMG IDL - format   >> RepositoryId if no ID pragma is encountered for it.      The issue is whether the OBV specification changes this default for   values or not     

Summary: 2. The current language mapping mixes both generated code with user      written code in the same source file.  This poses a very complex "tool"      issue for IDL compilers which is unnecessarily complex.    

Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is      inconsistent with current OBV terminology.    

 received issue