Issues for IDL Script FTF Discussion list
To comment on any of these issues, send email to idlscript-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 3779: IDLScript : Binding OMG IDL Union
Issue 3780: IDLScript : Object Registration
Issue 4500: Typos in the OMG TC Document formal/01-06-05
Issue 4501: Alignment with CORBA Object URL formats
Issue 4502: Alignment with CORBA 2.4.2
Issue 4503: Default-initialization for structs/unions/arrays/user exceptions/valuetypes
Issue 3779: IDLScript : Binding OMG IDL Union (idlscript-ftf)
Click here for this issue's archive.
Source: Laboratoire d`Informatique Fondamentale de Lille (Dr. Christophe Gransart, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
What are you doing in the case of there is no field associated to a particular
discriminator value? (page 6-70)
Resolution: Add an example for this case
Revised Text: Section 3.7.3 added the sentence and an example.
In the case of there is no field associed with the discriminator value, the union
creation is simply done by setting the discriminator value.
>>> c = AnUnion(3)
>>> c
AnUnion(3)
Actions taken:
August 3, 2000: received issue
Issue 3780: IDLScript : Object Registration (idlscript-ftf)
Click here for this issue's archive.
Source: Laboratoire d`Informatique Fondamentale de Lille (Dr. Christophe Gransart, nobody)
Nature: Uncategorized Issue
Severity:
Summary: In the document, the object registration with the POA needs to be extended.
(page 6-88)
Resolution: The text for the object registration with the POA is extended
Revised Text: Section 3.13.4 added the sentences
PortableServer::POA, PortableServer::current and PortableServer Policies
interfaces must be implemented by the scripting engine.
PortableServer::POAManager, PortableServer::AdapterActivator, PortableS
erver::ServantManager, PortableServer::ServantActivator,
PortableServer::ServantLocator are implemented by user classes written in
IDLScript.
Actions taken:
August 3, 2000: received issue
Issue 4500: Typos in the OMG TC Document formal/01-06-05 (idlscript-ftf)
Click here for this issue's archive.
Source: INRIA (Dr. Philippe Merle, nobody)
Nature: Uncategorized Issue
Severity:
Summary: Typos in the OMG TC Document formal/01-06-05
--------------------------------------------
Some typos are present in the CORBA Scripting Language Specification v1.0
(OMG TC Document formal/01-06-05):
* In Section 1.4.6 page 1-10, replace:
GridSevice::Coord(100,100)
by:
GridService::Coord(100,100)
* In Chapter 1, replace all:
Factory
by:
GridFactory
because factory is an OMG IDL keyword and
could not be used as an OMG IDL identifier.
Resolution: see above
Revised Text: In formal/01-06-05, page 1-10, replace
GridSevice::Coord(100,100)
by
GridService::Coord(100,100)
In formal/01-06-05, pages 1-6, replace Factory by _Factory.
Actions taken:
August 16, 2001: received issue
December 11, 2002: closed issue
Discussion: The typo must be corrected.
As factory is an OMG IDL keyword, an underscore must be added before the Factory identifier to escape from the OMG IDL keyword interpretation
Issue 4501: Alignment with CORBA Object URL formats (idlscript-ftf)
Click here for this issue's archive.
Source: INRIA (Dr. Philippe Merle, nobody)
Nature: Uncategorized Issue
Severity:
Summary: The CORBA Scripting Language Specification v1.0 (OMG TC Document formal/01-06-05)
refers to old iioploc:// and iiopname:// INS URL formats.
Here is a list of changes to align IDLscript with recent CORBA Object URL formats:
* In Section 1.4.5 page 1-9, replace:
(i.e., iioploc:// and iiopname://)
by:
(i.e., corbaloc and corbaname)
* In Section 1.4.5 page 1-9, replace:
factory = GridService.Factory("iioploc://an_IP_host_name:5000/factory")
by:
factory = GridService.GridFactory("corbaloc:iiop:an_IP_host_name:5000/factory")
* In Section 3.12.3 page 3-22, replace all:
iioploc://host:port/object_name
by:
corbaloc:iiop:host:port/object_name
* In Section 3.12.3 page 3-22, replace:
iiopname://host:port/path_into_a_naming_context
by:
corbaname::host:port#path_into_a_naming_context
* In Section 3.12.3 page 3-22, add a cross reference to the Section 13.6.7
of the CORBA 2.4.2 specification (i.e. Object URLs).
Resolution: see above
Revised Text: In formal/01-06-05, section 1.4.5, page 1-9, replace
with the Interoperable Name Service URL formal (i.e., iioploc:// and iiopname://)
by
with CORBA Object URL formats (e.g., corbaloc and corbaname)
In formal/01-06-05, section 1.4.5, page 1-9, replace
"iioploc://an_IP_host_name:5000/factory"
by
"corbaloc:iiop:an_IP_host_name:5000/factory"
In formal/01-06-05, section 3.12.3, page 3-22, replace
The object reference is given through the following formats: the standard CORBA IOR (i.e., "IOR:...") or the Interoperable Name Service URL (i.e., "iioploc://host:port/object_name" and "iiopname//host:port/path_into_a_naming_ context").
by
Accepted formats for stringified object references are described in Section 13.6.9 "Stringified Object References", page 13-24 and Section 13.6.10 "Object URLs", page 13-25 of the CORBA 3.0 Specification.
In formal/01-06-05, section 3.12.3, page 3-22, replace
>>> objref = AnotherFoo("iioploc://host:port/name")
by
>>> objref = AnotherFoo("corbaloc:iiop:host:port/name")
Actions taken:
August 16, 2001: received issue
August 16, 2001: received issue
December 11, 2002: closed issue
Discussion: The CORBA Scripting Language Specification v1.0 (OMG TC Document formal/01-06-05) refers to old iioploc:// and iiopname:// INS URL formats.
Replace them by the corbaloc and corbaname CORBA Object URL formats.
Issue 4502: Alignment with CORBA 2.4.2 (idlscript-ftf)
Click here for this issue's archive.
Source: INRIA (Dr. Philippe Merle, nobody)
Nature: Uncategorized Issue
Severity:
Summary: The CORBA Scripting Language Specification v1.0 (OMG TC Document formal/01-06-05)
is aligned with CORBA version 2.3 (see note at page 1-1).
It is needed to align this specification with CORBA 2.4.2.
Here is a list of alignment requirements:
* In Section 2.2 page 2-3, replace all:
CORBA 2.3
by:
CORBA 2.4.2
* In Section 3.11.3 page 3-17 Table 3-2, add new IDLscript identifiers
to refer recent CORBA system exceptions:
* CORBA.REBIND
* CORBA.TIMEOUT
* CORBA.TRANSACTION_UNAVAILABLE
* CORBA.TRANSACTION_MODE
* CORBA.BAD_QOS
* In Section 3.11.3 and 3.11.4 page 3-18, replace all:
CORBA.CompletionStatus
by:
CORBA.completion_status
* In Section 3.13.5 page 3-29, replace:
CORBA::BAD_INV_ORDER
by:
CORBA::UNKNOWN with minor code equals to 2 | OMGVMCID
* In Section 3.18.1 page 3-40 Table 3-6, add recent CORBA::Object operations
and their IDLscript reflection:
* get_client_policy is reflected by _get_client_policy
* get_policy_overrides is reflected by _get_policy_overrides
* validate_connection is reflected by _validate_connection
* Add the new section 3.11 (i.e. Binding for OMG IDL Fixed) at page 3-16
for describing rules for OMG IDL fixed types.
Then next sections must be renumbered.
* Adding binding rules for OMG IDL local interfaces allowing to access
to all Policy and Current objects, interceptors, etc.
This requires to add a new section in the Chapter 3
or update the section 3.12 (i.e. Binding for OMG IDL Interface).
Resolution: see above
Revised Text: Following must be applied to the formal/01-06-05 document.
At pages 1-1, 2-3, 2-5, 3-27, 3-34, and 3-35, replace CORBA 2.3 by CORBA 3.0.
At page 2-5, replace Table 3-2 on page 3-4 by Table 3-2 on page 3-3,
Table 3-4 on page 3-5 by Table 3-4 on page 3-4,
Table 3-5 on page 3-6 by Table 3-5 on page 3-5.
At page 3-17, Table 3-2, add the exception identifiers CORBA.REBIND, CORBA.TIMEOUT, CORBA.TRANSACTION_UNAVAILABLE, CORBA.TRANSACTION_MODE, CORBA.BAD_QOS, CORBA.INVALID_ACTIVITY, CORBA.ACTIVITY_COMPLETED, and CORBA.ACTIVITY_REQUIRED.
At page 3-18, replace all occurrences of CompletionStatus by completion_status.
At page 3-29, replace CORBA::BAD_INV_ORDER by CORBA::UNKNOWN with minor code equal to 2 | OMGVMCID.
At page 3-40, Table 3-6, add the following lines at the end of the table
get_client_policy _get_client_policy
get_policy_overrides _get_policy_overrides
validate_connection _validate_connection
get_component _get_component
At pages 3-41 and 3-42, Table 3-7, add the following lines
id id
register_initial_reference register_initial_reference
At page 3-1, Table contents, add cross references to the Section "Binding for OMG IDL Fixed".
At page 3-16, before section 3.11, add the following section
3.11 Binding for OMG IDL Fixed
All IDL fixed types and values are directly accessible from the IDLscript interpreter. They are represented by internal objects managed by the Interface Repository cache of the IDLscript interpreter.
3.11.1 OMG IDL Example
Consider the following example which presents the Money fixed type with nine significant digits and a scale factor of two. Only named fixed types are supported by IDLscript, no binding for anonymous fixed types is provided.
// This definition can be located inside or outside an IDL module or interface
typedef fixed<9,2> Money;
3.11.2 IDLscript Representation
In IDLscript, access to an IDL fixed type is done simply by providing its IDL fixed type identifier. This identifier can be prefixed by its module or interface scopes where it is defined. The evaluation of an IDL fixed type displays the IDL definition of this type definition.
>>> Money
< OMG-IDL typedef fixed<9,2> Money; >
>>> t = Money
>>> t
< OMG-IDL typedef fixed<9,2> Money; >
The previous code presents the access to the Money fixed type. As IDL fixed types are represented by IDLscript objects, they can be assigned to variables to create aliases, compared and passed as arguments to procedures.
3.11.3 Fixed Values
The creation of an IDL fixed value is achieved by the calling notation with an initial value. When the given value is of an integer, floating, or fixed type, the interpreter automatically coerces this given value to the required IDL fixed value. If the given value is a string, the interpreter automatically converts the string to a fixed value or throws a CORBA::DATA_CONVERSION exception when the string does not denote a valid fixed value.
>>> mi = Money(10)
>>> mi
Money(10)
>>> Money(100.56)
Money(100.56)
>>> Money("999.99")
Money(999.99)
>>> try {
m = Money("not a valid fixed value string")
} catch(CORBA.DATA_CONVERSION e) {
println("Data conversion exception!")
};
Data conversion exception!
>>> mf = Money(mi)
>>> mf
Money(10)
>>> mf._type
< OMG-IDL typedef fixed<9,2> Money; >
>>> mf._is_a(Money)
true
The previous code presents some examples of IDL fixed value creations with different initial value types. As IDL fixed values are represented by IDLscript objects, it is possible to use common value attributes and methods such as _type and _is_a.
Moreover, IDLscript fixed values have specific attributes and methods enumerated in Table 3?2.
Table 3-2 The IDLscript Fixed Value Functionalities
Functionality Explanation
f.digits Returns the smallest digits that can hold the complete f fixed object.
f.scale Returns the smallest scale that can hold the complete f fixed object.
f.round(s) Returns a new fixed object equal to the f fixed object rounded down the specified s scale, where s is an unsigned short. If the new scale requires the value to lose precision on the right, the round method will round away from zero values that are halfway or more to the next absolute value for the new fixed precision.
f.truncate(s) Returns a new fixed object equal to the f fixed object truncated to the specified s scale, where s is an unsigned short. If the new scale requires the value to lose precision on the right, the truncate method always truncates the value towards zero.
Consider the following examples:
>>> m = Money(100.56)
>>> m.digits
5
>>> m.scale
2
>>> m.round(0)
Money(101)
>>> m.round(1)
Money(100.6)
>>> m.round(2)
Money(100.56)
>>> m.truncate(0)
Money(100)
>>> m.truncate(1)
Money(100.5)
>>> m.truncate(2)
Money(100.56)
Actions taken:
August 16, 2001: received issue
December 11, 2002: closed issue
Discussion: The CORBA Scripting Language Specification v1.0 (OMG TC Document formal/01-06-05) must be aligned with the CORBA 3.0 Specification (formal/02-06-01):
· Add recent CORBA system exceptions,
· Replace CompletionStatus by completion_status,
· Replace the BAD_INV_ORDER exception by UNKNOWN.
· Add recent CORBA::Object operations,
· Add recent CORBA::ORB operations,
· Add a section describing the binding for OMG IDL fixed types and values.
No changes are required for local interfaces as they are reflected by the IDLscript interpreter and implemented by user scripts as normal interfaces are, i.e. through the rules already defined in section 3.13 "Binding for OMG IDL Interface" and section 3.14 "Implementing OMG IDL Interfaces" of the CORBA Scripting Language Specification.
Issue 4503: Default-initialization for structs/unions/arrays/user exceptions/valuetypes (idlscript-ftf)
Click here for this issue's archive.
Source: INRIA (Dr. Philippe Merle, nobody)
Nature: Uncategorized Issue
Severity:
Summary: In the CORBA Scripting Language Specification v1.0 (OMG TC Document formal/01-06-05),
creating a struct, union, array, user exception or valuetype required to provide
a value for each field.
e.g. Section 3.6.3 "Structure Values" page 3-8:
"The creation of an IDL structure value is achieved by the calling notation
(IDLType(field1,...,fieldn)). The interpreter checks if the number of
given values is equal to the number of the expected IDL fields..."
Ditto in sections 3.7.3 page 3-9, 3.10.3 page 3-15, 3.11.6 page 3-20,
and 3.14.3 page 3-30.
For complex structs, unions, arrays, user exceptions and valuetypes,
Chris Oliver (coliver@mminternet.com) think it would be much more user-friendly
to always allow the "constructor" to be optionally called with zero arguments
which would result in default-initialization of the complex value.
The user can then incrementally fill out the contents of complex values,
for example:
nc = CosNaming.NameComponent()
nc.id = "a"
nc.kind = "b"
Since DynamicAny::DynAny in CORBA 2.3 provides default-initialization,
this requires no extra effort for the implementor.
-------------------------------------------------------------------------
Resolution: see above
Revised Text: Following changes must be applied to the formal/01-06-05 document.
At page 3-8, section 3.6.3, replace
The interpreter checks . . .
by
If no argument is provided, all the struct fields are (recursively) initialized to their default values. If arguments are provided, the interpreter checks . .
At page 3-8, section 3.6.3, add following examples
>>> p0 = Point()
>>> p0
Point(0,0)
>>> tp0 = TwoPoints()
>>> tp0
TwoPoints(Point(0,0),Point(0,0))
At page 3-10, section 3.7.3, replace
The interpreter checks . . .
by
If no argument is not provided, the union discriminator is set to a value consistent with the first named member of the union and the associated union member is (recursively) initialized to its default value. If only the discriminator is provided, the associated union member is (recursively) initialized to its default value. If both values are provided, the interpreter checks . . .
At page 3-10, section 3.7.3, add following examples
>>> AnUnion()
AnUnion(0,0)
>>> AnUnion(1)
AnUnion(1,0)
At page 3-15, section 3.10.3, replace
The type of each value . . .
by
If no value is provided, all the array items are (recursively) initialized to their default values. If values are provided, the type of each value . . .
At page 3-15, section 3.10.3, add following examples
>>> a = ArrayLong()
>>> a
ArrayLong(0,0,0,0,0,0,0,0,0,0)
>>> a = ArrayPoint()
>>> a
ArrayPoint(Point(0,0),Point(0,0),Point(0,0),Point(0,0),
Point(0,0),Point(0,0),Point(0,0),Point(0,0),Point(0,0),
Point(0,0))
At page 3-20, section 3.11.6, replace
The interpreter checks . . .
by
If no argument is provided, all the user exception fields are (recursively) initialized to their default values. If arguments are provided, the interpreter checks . . .
At page 3-20, section 3.11.6, add the following example
>>> u = Exception()
>>> u
Exception("",Months.January,Point(0,0))
Actions taken:
August 16, 2001: received issue
December 11, 2002: closed issue
Discussion: In order to simplify the creation of complex structs, unions, arrays, and user exceptions, the initialization notation of these types can accept zero argument. Then the fields of the created objects are initialized to their default values.
For value types, no change is required as they are created by calling value factory operations