Document Number: J4/03-0016
January 16, 2002
D-10 Page 1 of 8
Subject:
Parameterized Classes and Interfaces (Kiesel/Reimann)
Author:
Thane A. Hubbell
Previous Version:
Not Applicable
References in Document:
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 1, Scope
6.
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 684, B.1,
7.
Implementor-defined language element list, Item 107
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 688,
8.
Implementor-defined language element list, Item 166
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 29, 7
9.
Compiler directing facility. Last paragraph of the section.
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 166. 9.3.12,
10.
Parameterized classes.
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 166,
11.
9.3.13, Parameterized interfaces.
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 176, 11.2.2,
12.
Class-ID Paragraph, Syntax Rule 4
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 180, 11.5.3,
13.
Interface-ID Paragraph, Syntax Rule 3
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 205,
14.
Repository Paragraph, 12.2.7.2, Syntax rules 3 and 7.
ISO/IEC FDIS 1989:2002, Programming language COBOL: Page 396, Table
15.
14 — Exception-names and exception conditions, EC-OO-RESOURCE.
Other References:
Document Number: J4/03-0016
January 16, 2002
D-10 Page 2 of 8
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-0016
January 16, 2002
D-10 Page 3 of 8
Question 1:
Page 1, 1 Scope, states:
“This International Standard does not specify:
…
The time at which parameterized classes are expanded.”
Question 1A:
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 1B:
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)?
Document Number: J4/03-0016
January 16, 2002
D-10 Page 4 of 8
Question 4b:
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.
It is clear to me (Hubbell) that the intent of parameterized classes and interfaces was to
allow substitution of class names only, and not something like a general copy/replacing.
Page 166, 9.3.12, Parameterized Classes, first paragraph (Emphasis added):
Document Number: J4/03-0016
January 16, 2002
D-10 Page 5 of 8
A parameterized class is a generic or skeleton class that has formal parameters that will
be replaced by one or more class-names or interface-names.
Using a parameterized class one can have a single coded class but use that class with
different names. Because of this complex rules for what is replaced, and when, are not
needed. The existing rule about expansion happening after text manipulation is
sufficient.
Problems do seem to exist in that there is no restriction in use of these classes and
interfaces and in actuality there is no restriction on specification of a parameterized
interface in the repository, in fact those rules seem vague:
From 9.3.12, Parameterized Classes:
“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. This class has its own factory object and is completely separate
from any other instance of the same parameterized class.”
I think what this really means to say is when a parameterized class is specified as the
argument of an EXPANDS clause in the REPOSITORY paragraph…etc. (As in question
3).
Our response to these defects is going to need to be discussed in light of the intent.
Note: This has an potentially significant impact on the Class Library development.
Question 1A:
While the list for Scope is not exhaustive, it should be complete. It will be amended to
mention interfaces as well as classes. The implementor-defined language element list,
item 107 will also be updated to include interfaces.
Question 1B:
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.”
Document Number: J4/03-0016
January 16, 2002
D-10 Page 6 of 8
Since the timing is specified, to a degree, this sentence should be part of the text
manipulation paragraph, rather than moving this to 9.3.12 or 9.3.13. Making it part of
7.1, Text Manipulation makes the implementor-defined language element correct.
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 replacement that any externalized class
name exists.
Question 3:
The questioners comment is correct. This wording will be corrected.
Question 4A, B and C
To be discussed
Question 5:
While the wording is inconsistent, the intent is not. Cleanup of this text will be left to a
future revision.
Question 6:
Syntax rule 7 has the same wording. “Specified” is more accurate than “Defined”,
however the present intent is clear. Cleanup of this text will be left to a future revision.
Question 7:
Good question. The wording will be changed.
Question 8:
To be discussed.
1.
Page 1, Scope, third item, second bulleted list, change to: “The time at which
parameterized classes and interfaces are expanded.”
Page 684, B.1 Implementor-defined language element list, Item 107, first sentence,
change to “Parameterized classes and interfaces (when expanded).
Page 29, 7, Compiler directing facility, last paragraph, last sentence, move to be a
Document Number: J4/03-0016
January 16, 2002
D-10 Page 7 of 8
new second paragraph of 7.1 Text Manipulation also on page 29. The text is: “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.”
4.
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 using the EXPANDS
phrase, a new class (an instance of a parameterized class) is created based on the
specification of the parameterized class.”
5.
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.”
Page 396, Table 14 — Exception-names and exception conditions, EC-OO-
6.
RESOURCE. Change to “Insufficient system resources to create the object.”
Unresolved Issues:
1.
Is the proposed change 5 correct? Is the original text even right? Is an INSTANCE
of an Interface created? What about item 4? Maybe the parenthetical should be
removed in both cases?
2.
I’m not sure what to do with question 4. I have my own trouble understanding what
was intended. How we proceed may depend on the answer to what can be replaced
as a parameter in a parameterized class or interface.
3.
I need help with the general question as I have extracted it for question 8. I can’t find
any rules that restrict such references. One potential solution is to say that they CAN
Document Number: J4/03-0016
January 16, 2002
D-10 Page 8 of 8
be used, and that the USING clause is just ignored. Maybe that’s what happens
anyway?
