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 1250: "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] Jira Issue CORBA23-235
Issue 1254: Grammar rule issue Jira Issue CORBA23-236
Issue 1281: Which exceptions should be raised? Jira Issue CORBA23-237
Issue 1285: Clarify semantics Jira Issue CORBA23-238
Issue 1321: public static org.omg.CORBA.ValueDef get_value_def(); Jira Issue CORBA23-239
Issue 1526: Problem with C++ language mapping for OBV Jira Issue CORBA23-240
Issue 1529: DynAny::get_value collision Jira Issue CORBA23-241
Issue 1685: OBV TypeCode problems Jira Issue CORBA23-243
Issue 1720: Abstract Interface issue (02) Jira Issue CORBA23-245
Issue 1727: Module separator within repository IDs Jira Issue CORBA23-242
Issue 1782: New OBV "supports" keyword conflicts with CosLifeCycle Jira Issue CORBA23-246

Issue 1250: "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] (obv-rtf)

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: 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: 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:  

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: 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: 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: 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: 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 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: The new OBV keyword "supports" collides with the operation "supports"   defined in CosLifeCycle::GenericFactory.