Document Number: J4/02-0156

July 24, 2002 

 

 

 

Page 1 of 2

Defect Report

Author: 

 

Karl Kiesel, Artur Reimann

Subject: 

 

Parameterized Classes and Interfaces

References:

Base Document ISO/IEC 1989:2002(E)

JUSTIFICATION:

I believe that the rules for parameterized classes and interfaces need to be corrected and clarified.

DISCUSSION:

General:

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?

Specifics:

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. 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?

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?

Document Number: J4/02-0156

July 24, 2002 

 

 

 

Page 2 of 2

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.

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.”

Question 1: Why is there not a corresponding requirement for interfaces (11.5.2, SR 3)?

Question 2: 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 3: 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.”

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?

6.

Page 205 SR 4 Change first instance of “defined” to “specified”.

7.

Page 396 table 14: What does “… to expand the object…” mean. Expansion of an object is not defined

anywhere.