Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 1 of 7
Subject:
Parameterized Classes and Interfaces (Kiesel/Reimann)
Author:
Thane A. Hubbell
Previous Version:
03-0016
References in Document:
1.
ISO/IEC1989:2002, Programming language COBOL: Page 1, Scope
2.
ISO/IEC 1989:2002, Programming language COBOL: Page 29, 7 Compiler directing
facility. Last paragraph of the section.
3.
ISO/IEC 1989:2002, Programming language COBOL: Page 166. 9.3.12,
Parameterized classes.
4.
ISO/IEC 1989:2002, Programming language COBOL: Page 166, 9.3.13,
Parameterized interfaces.
5.
ISO/IEC 1989:2002, Programming language COBOL: Page 176, 11.2.2, Class-ID
Paragraph, Syntax Rule 4
6.
ISO/IEC 1989:2002, Programming language COBOL: Page 180, 11.5.3, Interface-ID
Paragraph, Syntax Rule 3
7.
ISO/IEC 1989:2002, Programming language COBOL: Page 205, Repository
Paragraph, 12.2.7.2, Syntax rules 3 and 7.
8.
ISO/IEC 1989:2002, Programming language COBOL: Page 396, Table 14 —
Exception-names and exception conditions, EC-OO-RESOURCE.
9.
ISO/IEC 1989:2002, Programming language COBOL: Page 684, B.1, Implementor-
defined language element list, Item 107
10.
ISO/IEC 1989:2002, Programming language COBOL: Page 688, Implementor-
defined language element list, Item 166
Other References:
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 2 of 7
Karl Keisel, (Karl.Kiesel @ fujitsu-siemens.com)
The defect was submitted directly to J4 by Mr. Keisel
General Discussion (From initial Defect report)
It seems that parameterized classes and interfaces can be referenced wherever
(regular) classes or interfaces are allowed. At least, we are not aware of any generic
rules that disallow such references, and the rules for specific clauses, statements, and
identifiers (normally?) don’t exclude parameterized classes or interfaces. For example,
an ‘INVOKE parm-class “NEW” or a ’01 or-1 OBJECT-REFERENCE parm-class’ seem
to be valid. What happens with such references? One would expect that they would
eventually be replaced by the name of the expansion generated through the EXPANDS
phrase. But parm-class is not a formal parameter, so it is not subject of the expansion
rules. It also cannot be specified as a formal parameter in a USING phrase of the
CLASS-ID, because this would require a repository entry for it (12.2.2 GR 9), which is
valid but would be ignored (12.2.7.2 GR 5 and 8).
The case becomes especially delicate when such a reference is to the class definition in
which it is defined: ‘Class-Id. xyz using p1. … Invoke xyz “New”’. Assume a client source
element that has a ‘Class abc expands xyz using q1’ in its repository paragraph. What
happens with the two invoke statements ‘Invoke abc “New”’ and ‘Invoke xyz “New”’. Both
seem to be valid, but do they make sense, and what is the result?
Additional Observations (Hubbell)
I had an email conversation with Mr. Kiesel where I asked him in his view the purpose or
Parameterized classes and interfaces and exactly what could/should be replaced by the
formalized parameters. He indicated that in his view the purpose was for only the class
name to be replaced. From his message:
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 3 of 7
Question 1:
Page 1, 1 Scope, states:
“This International Standard does not specify:
…
The time at which parameterized classes are expanded.”
Why are parameterized interfaces not mentioned here? And is this really intended to be
an exhaustive list? We believe it is not, so a “for example” should be included.
Now, section 1 is not a normative part of the standard. However, section 7, last
paragraph does have such a statement (and it includes parameterized interfaces). Item
107 of the list of implementor-defined elements points to it, but refers to classes only.
Question 1a:
There is still another entry in that list, item 166, which erroneously points to section 7.1.
And why is this under “Compiler-directing facility”. Wouldn’t 9.3.12 and 9.3.13 be more
appropriate places to talk about the timing of expansion?
Question 2:
Page166, 9.3.12/9.3.13 last paragraphs: What is the 'same actual parameter'; wouldn’t’ it
be better to say the same externalized name?
Question 3:
Page 166: Parameterized classes and interface, 3rd paragraphs of each: A 'new
instance' is not created when a parameterized class/interface is specified in the
repository paragraph, but when an expansion of a parameterize class it is defined by
means of the EXPANDS phrase.
Question 4:
Page 176, 12.2.2 Class-Id, SR 4: “4) … Class-name-2 shall not be the name of a
parameterized class that expands class-name-1 directly or indirectly.”
(NOTE: Submitter means 11.2.2)
Question 4a:
Why is there not a corresponding requirement for interfaces (11.5.2, SR 3)?
Question 4b:
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 4 of 7
How can a parameterized class expand another class? A parameterized class cannot
include an EXPANDS phrase (12.2.7.2 SR 3). What is probably meant is “… that is a
direct or indirect expansion of class-name-1, if that is a parameterized class.”
Question 4c:
What does “indirectly” mean? A parameterized class cannot have an EXPANDS phrase
(see question 2 above). The only interpretation we can think of is the case where the
inherited class is an expansion of a subclass of the class being defined. But then the rule
should better be “…Class-name-2 shall not be the name of an expansion of class-name-
1, if that is a parameterized class, or of any subclass of class-name-1.”
Question 5:
Pages 177/180: The corresponding rules GR6 for CLASS-ID and GR4 for INTERFACE-
ID are incompatibly worded; 'may be specified... only...' vs. 'shall be specified... only...' -
Was this forgotten when “may/shall” hunting took place?
Question 6:
Page 205 SR 4 Change first instance of “defined” to “specified”.
Question 7:
Page 396 table 14: What does “… to expand the object…” mean. Expansion of an object
is not defined anywhere
Question 8: (Constructed by Hubbell from the Introductory text of the submitter)
What restricts reference to a parameterized class or interface (one that has a USING
phrase) as if it were are regular (non parameterized) class or interface?
Proposed solutions sometimes embedded in the questions.
J4 discussed each question and proposed response, making suggestions in wording and
direction.
Question 1:
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 5 of 7
While the list for Scope is not exhaustive, it should be complete. It will be amended to
mention interfaces as well as classes. [Technical Corrigendum change 1]
B.1, Implementor-defined language element list, item 107, will be updated to include
interfaces. [Technical Corrigendum change 8]
Question 1a:
Item 166 of the implementor-defined language element states: “Text manipulation (stage
of processing parameterized class expansion). This item is required. This item need not
be documented in the implementor's user documentation. (7.1, Text manipulation)”.
The notation about when parameterized classes and interfaces are expanded is in the
last paragraph of 7.0 compiler directing facility, page 29 and states: “The manner and
time of expansion of parameterized classes and parameterized interfaces is defined by
the implementor, except that it occurs after the text manipulation stage of processing.”
The information in the implementor-defined language element list is consistent with the
information presented in the body of the text. The committee will consider better
placement for the discussion for the timing of expansion of parameterized classes and
interfaces in a future revision or amendment.
Question 2:
The same actual parameter is correct. The class is created as a separate class based
on the parameters, which are not externalized names. Given that the only parameter
replacement that is desired is a class or interface name replacement, the distinction is
semantic, but accurate. It is not until after the expansion that any externalized class
name exists.
Question 3:
The questioners comment is correct. This wording will be corrected. [Technical
Corrigendum change 2 and 3]
Question 4A, B and C
When the rule was added prohibiting the expands phrase in a parameterized class, the
rules for a parameterized interface were corrected, but rules for parameterized a
parameterized class were not. 11.2.2, Syntax rule 4 will be corrected. [Technical
Corrigendum change 4]
Question 5:
While the wording is inconsistent, the intent is not. Cleanup of this text will be left to a
future revision.
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 6 of 7
Question 6:
Syntax rule 7 has the same wording. Specified means a reference. Here it is a
definition. The new class is defined here, so defined is correct for class-1. No change
will be made.
Question 7:
Good question. The wording will be changed. [Technical Corrigendum change 7]
Question 8:
The general rules for repository paragraph will be updated to make it clear that the only
valid reference to the parameterized interface or class names is in the repository
paragraph. [Technical Corrigendum change 5 and 6]
1.
Page 1, Scope, third item, second bulleted list, change to: “The time at which
parameterized classes and interfaces are expanded.”
2.
Page 166, 9.3.12, Parameterized Classes, third paragraph, first sentence which
states:
“When a parameterized class is specified in the REPOSITORY paragraph, a new
class (an instance of a parameterized class) is created based on the specification of the
parameterized class.”
Replace with:
“When a class is specified in the REPOSITORY paragraph in an EXPANDS phrase,
a new class (an instance of a parameterized class) is created based on the specification
of the parameterized class.”
3.
Page 166, 9.3.13, Parameterized Interfaces, third paragraph, first sentence which
states:
“When a parameterized interface is specified in the REPOSITORY paragraph, a new
interface (an instance of a parameterized interface) is created based on the specification
of the parameterized interface.”
Replace with:
“When an interface is specified in the REPOSITORY paragraph using the EXPANDS
phrase, a new interface (an instance of a parameterized interface) is created based on
the specification of the parameterized interface.”
Document Number: J4/03-0051
March 1, 2003
D-10.1 Page 7 of 7
4.
Page 176, Class-Id, 11.2.2, Syntax rules, Syntax rule 4, remove the second
sentence.
5.
Page 206, Repository, 12.2.7.3, General Rules, General Rule 1, add a second
paragraph: “If class-name-1 is a class described with the using phrase, class-name-1
may only be specified in the repository paragraph.
6.
Page Page 207, Repository, 12.2.7.3, General Rules, General Rule 7, add a second
paragraph: “If interface-name-1 is an interface described with the using phrase,
interface-name-1 may only be specified in the repository paragraph.
7.
Page 396, Table 14 — Exception-names and exception conditions, EC-OO-
RESOURCE. Change to “Insufficient system resources to create the object.”
8.
Page 684, B.1 Implementor-defined language element list, Item 107, first sentence,
change to “Parameterized classes and interfaces (when expanded).
1.
Consider better placement for the discussion for the timing of expansion of
parameterized classes and interfaces in a future revision or amendment.
2.
Page 176, Class-Id, 11.2.3, General Rules, consider making the wording for GR6
and the wording for GR4 for Interface-Id on page 189 consistent.
Unresolved Issues:
None
