Issue 3351: Python Issue: TypeCode constants?                                                                                                                                                                       (python-ftf)
Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam@camros.com)
Nature: Uncategorized Issue
Severity: 
Summary: Are type code constants generated by the IDL compiler, and if so are they 
available for use by developers (ie, not implementation specific)?

If type code constants are not available, then developers have to rememeber 
the repository ids of certain IDL declarations (python-noops like typedef) in 
order to get a typecode from CORBA.TypeCode (since CORBA.id is most likely no 
help in this instance).

I propose that type code constants be made available to developers using some 
standardized naming scheme (_tc_XXX?).

Resolution: see above
Revised Text: 
Actions taken:
February 22, 2000: received issue
December 3, 2001: closed issue
Discussion: 
Close with no change. The analysis is incorrect: python-noops like typedef do get Python symbols that can be passed to CORBA.id, so there is no need to remember the repository ID. CORBA.TypeCode is sufficient to get the type code of all types.
End of Annotations:=====
Date: Tue, 22 Feb 2000 16:11:31 -0500 (EST)
Message-Id: <200002222111.QAA23427@emerald.omg.org>
To: python-ftf@omg.org, issues@omg.org
Subject: Python Issue: TypeCode constants?
From: "Jeffrey A. Marshall" <jam@camros.com>
X-Mailer: TWIG 2.1.1
Content-Type: text
X-UIDL: A&%e9'FQd9(KEe91fC!!

Are type code constants generated by the IDL compiler, and if so are
they 
available for use by developers (ie, not implementation specific)?

If type code constants are not available, then developers have to
rememeber 
the repository ids of certain IDL declarations (python-noops like
typedef) in 
order to get a typecode from CORBA.TypeCode (since CORBA.id is most
likely no 
help in this instance).

I propose that type code constants be made available to developers
using some 
standardized naming scheme (_tc_XXX?).

-- 
Jeffrey A. Marshall

Camros Corporation
Email  jam@camros.com
Voice  703-876-1700 ext. 10
Fax    703-876-1818
       http://www.camros.com/



Date: Mon, 5 Mar 2001 14:32:59 +0100 (MET)
Message-Id: <200103051332.OAA02653@pandora.informatik.hu-berlin.de>
X-Authentication-Warning: pandora.informatik.hu-berlin.de: loewis set
sender to loewis@informatik.hu-berlin.de using -f
From: Martin von Loewis <loewis@informatik.hu-berlin.de>
To: python-ftf@omg.org
Subject: Draft resolutions for issue 3351
User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6
(sparc-sun-solaris2.6) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-UIDL: Xc^!!D7A!!jZOd9#`+!!

Dear Colleagues,

I'm sending a series of proposals for resolutions for individual
issues. If there is no apparent disagreement on the proposals, I'll
put together a vote later this week.

In issue 3351, the submitter writes

> If type code constants are not available, then developers have to
> rememeber the repository ids of certain IDL declarations
> (python-noops like typedef) in order to get a typecode from
> CORBA.TypeCode (since CORBA.id is most likely no help in this
> instance).

This analysis is incorrect: python-noops like typedef do get Python
symbols that can be passed to CORBA.id, so there is no need to
remember the repository ID. The submitter then requests

> I propose that type code constants be made available to developers
> using some standardized naming scheme (_tc_XXX?).

Proposed resolution: This is closed with no action; to obtain typecode
constants, the CORBA.typecode function is sufficient.

Martin