Issue 73:  Do typecodes need literal constant representations in all mappings? (orb_revision)
Source:  (, )
Nature:  Uncategorized
Severity: 
Summary: Summary: Section 6.7 of the CORBA 2 spec constrains the representation of typecodes such that typecode "literals" can be placed in C include files. Is this meant?

Resolution:  The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi
Revised Text:  Remove para 3 of section 10.7 Close in 2.3a after incorporating change.
Actions taken:
August 13, 1996: Received issue
February 22, 1999: closed issue
Discussion: 

End of Annotations:=====

From geoff  Tue Aug 13 12:10:51 1996
Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34)
	id AA10934; Tue, 13 Aug 1996 12:10:51 -0400
Date: Tue, 13 Aug 1996 12:10:51 -0400
From: geoff (Geoffrey Speare)
Message-Id: <9608131610.AA10934@amethyst.omg.org.omg.org>
To: issue-logger@omg.org
Subject: Core issue:  Do typecodes need literal constant representations in all language mappings?
X-Omg-Issue: 73

Date: Thu, 8 Aug 1996 11:38:16 PDT
Sender: Bill Janssen <janssen@parc.xerox.com>
From: Bill Janssen <janssen@parc.xerox.com>
To: orbos@omg.org
Subject: Core issue:  Do typecodes need literal constant representations in all language mappings?
Cc: ilu-core.PARC@xerox.com

In section 6.7 of the CORBA 2 spec, under the description of TypeCodes,
the following text appears:

``TypeCodes are themselves values that can be passed as invocation
arguments. To allow different ORB implementations to hide extra
information in TypeCodes, the representation of TypeCodes will be opaque
(like object references). However, we will assume that the
representation is such that TypeCode "literals" can be placed in C
include files.''

This interesting constraint does not seem to be referenced anywhere in
the C mapping.

1)  Is this constraint meant, at all?  Or is it a historical artifact in
the text?

2)  If meant, what does "literal" mean?  My colleague Mike Spreitzer
speculates as follows:

> It's not clear to me exactly what this says.  I can think of at least three
> interpretations:

> (1) a TypeCode "literal" must be a C "expression";

> (2) a TypeCode "literal" must be a C "expression" that is an r-value, not an
> l-value, and hence does not admit modification;

> (3) a TypeCode "literal" must be a C "constant expression".

> However, that does not address the differences among (1),
> (2), and (3).  Clearly, there is a progression of strictness of those
interpretations, and so (3) is the safest [interpretation].

3)  If meant, how is it intended to be generalized to non-C languages
like Java and Python?

Bill