J3/00-276r1
To:      J3
From:    Malcolm Cohen
Subject: Issues 17-19
Date:    14th September 2000

1. Introduction

This paper attempts to gather together 00-247 and 00-272.

The crucial insight here is that after the component ordering issues of i/o
and structure constructors is sorted out (by another paper), there is no
reason not to call the "parent thingy" a component.

Note that this paper does not attempt to fix the structure constructor
problems noted in 00-272, and thus does not address issue 211.


2. Edits to 00-007r2

[52:43+] Insert note 4.41a
  "Inaccessible components and bindings of the parent type are also
   inherited, but they remain inaccessible in the extended type.
   Inaccessible entities occur when the type being extended is accessed via
   USE association and has a private entity."
{This attempt at clarification may belong in annex C?}

[53:4-6] Replace with
  "An object of extended type has a scalar nonpointer nonallocatable
   <<parent component>> with the type and type parameters of the parent
   type, consisting of all the components inherited from the parent type.
   The name of this component is the parent type name.  Components of the
   parent component are <<inheritance associated>> (14.6.4) with the
   corresponding components inherited from the parent type."
{Define the parent component.}
{NOTE TO EDITOR: Insert "inheritance association" into the index.}
{Also, say that the inherited components are associated with the components of
 our parent component.  We don't really need to put in a reference, since the
 other section says very little; but we do so for completeness.}

[53:7-16] Delete J3 note 17.
{We now call the parent subobject a component.}

[53:17] Replace "subobject denoted by the parent type name"
        with    "parent component"
{Use new term.}

[53:20-22] Replace "have neither" with "not have",
           delete "nor ... type",
           Make the whole thing a note.
{Use our new terminology; make it a note because it is covered by the old
 rules in ch14 now that the parent subobject is a component.}

[55:36-37] Replace "component that has the same name as the parent type"
           with "parent component".
{Use our new term to improve readability and correctness.}

[55:38-41] Delete J3 note 19.
{The parent subobject is now a component.}

{Note to J3 (not the standard): since 4.5.3.1 says that components of the
 immediate base type are included in the extended type, we don't have to
 extend the "scope" of a component-name to include extension types.  They
 are there already, at least when they are accessible.}

[348:14-15] Delete "or".  Before "." insert ", or inheritance association".
{Add inheritance association to our list of association types.}

[355:32+] Insert new section
  "14.6.4 Inheritance association
{NOTE TO EDITOR: Insert reference to inheritance assoc into the index.}
   Inheritance association occurs between components of the parent component
   and the components inherited by type extension into an extended type
   (4.5.3.1).  This association is persistent and is not affected by the
   accessibility of the parent component or the inherited components."
{Summarise the effects of inheritance association, in particular that it is
 invariant.}

[402:26+] Insert new glossary entry
  "<<inheritance association>> (4.5.3.1, 14.6.4) The relationship between the
   <inherited> components and the <parent component> in an extended type."
{Describe our new concept in the glossary.}

[404:26-28] Move to correct alphabetic position, viz [404:29+].

[404:29-] Insert new entry before the "parent type" entry:
  "<<parent component>> (4.5.3.1) The component of an entity of extended
   type which corresponds to its inherited portion."

===END