J3/00-272
To:      J3
From:    Malcolm Cohen
Date:    4th September 2000
Subject: Issues 17-19 and 211

1. Introduction

This paper is a revision of 00-148.

Issue 17 says
  "...
   I'm bothered by having a component name that isn't the name of a
component.
   Perhaps we should use different terminology such as subobject name ..."

I concur.

Issue 18 says
  "Should the above not be a constraint?  Fix up grandparents."

The answer to the question is No, but it ought to be part of our scoping
rules
(which do have similar status as constraints in requiring violation to be
diagnosed).

I concur with the second commandment.

Issue 19 says
  "but the name ... is not a component ...."

I concur.

Issue 211 says
  "\"flattened form\" is used ... but ... nowhere defined"

I concur.  Two solutions are provided for this problem!

2. Further remarks

(1) Our use of "parent" etc. is not completely intuitive.
    It would be better if we used

    Old term                       New term
    --------                     --------
    base type                      root type
    parent/grandparent/... type  base type
    parent type                    immediate base type

    This paper does not make this change.

3. Nested form is inherently broken

Given the following type definitions:

  MODULE doubly_linked_lists
    TYPE,EXTENSIBLE :: list
      CLASS(list),POINTER :: prev => NULL(), next => NULL()
    END TYPE
    ...
  END MODULE

Then in the program

    USE doubly_linked_lists
    TYPE,EXTENDS(list) :: my_item_type
      REAL value
    END TYPE
    CLASS(list),POINTER :: list_head
    TYPE(my_item_type) :: x

the structure constructor in

    x = my_item_type(list_head,value=3.5)

means what?

It could be
(1) nested form:
      x%list = list_head
      x%value = 3.5
(2) flattened form: list_head is providing the POINTER association for
      x%prev => list_head
      x%next => NULL()       ! Default value
      x%value = 3.5

Basically, "nested form" is a complication too far.
It provides no more real functionality than the normal ("flattened form")
structure constructor.  We should delete it.

NB: We do not want to delete the "flattened form", because that is how
people will expect type extension to work - like it is really extending the
type, not like some syntactic sugar layered over encapsulation.

4. Edits to 00-007r2

[53:4-6] Replace with
         "An object of extended type has a <<parent subobject>> with the
          type and type parameters of the parent type, consisting of all of
          the components inherited from the parent type.  The name of the
          parent subobject is the parent type name."
{Define a term for the parent subobject.}

[53:7-16] Delete J3 note 17.
{We no longer call the name of the parent subobject a "component name".}

[53:17] Replace "subobject denoted by the parent type name" with
        "parent subobject name".
{Improve readability by using our new term.}

[53:19+] Insert new paragraph
  "The <<subobject names>> of a nonextensible type or of a base type are the
   names of its components.  The subobject names of an extended type are the
   name of its parent subobject, the subobject names of its parent type, and
   the names of its additional components."
{Define new term "subobject name" we can use instead of component name when
we
 want to include the parent subobject designator(s).  Note that it is
defined
 recursively so that "grandparent" names are included.}

[53:20-22] Replace "have neither" with "not have",
           Replace "accessible component" with "accessible subobject name",
           Delete "nor ... type",
           Make the whole thing a note.
{Use our new terminology; make it a note because it will be covered by the
 scoping rules in ch14.}

[53:23-25] Delete J3 note 18.

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

??IF (delete_nested_form)

[55:35-37] Delete nested form.
{We do not need to define flattened form because it is the usual form.}

??ELSE

[55:37+] Add to end of paragraph
         "In the <<flattened form>>, a value is provided for each component
of
          the extended type."
{Add a definition of "flattened form".}

??ENDIF

[55:38-41] Delete J3 note 19.
{We don't call the parent subobject a component any more.}

[55:42-46] Delete J3 note 211.
{We either now have a definition of "flattened form", or no longer need
one.}

[56:1-2] Delete superfluous remark about flattened form.
{It follows from [55:23-24] anyway.}

??IF (delete_nested_form) THEN

[56:3-14] Delete nested form examples.

??ENDIF

[96:37] Replace "name of a component" with "subobject name".
{Make parent subobjects usable.}

[342:5] Replace "components, and binding names" with
         "bindings, and named subobjects".
{Move scoping requirement from ch4 to ch14.}

??IF (.NOT.delete_nested_form) THEN

[402:1+] Insert new entry
  "<<flattened form>> (4.5.6) The form of a structure constructor for an
   entity of extended type in which a value is provided for each inherited
   component."

[404:9+] Insert new entry
  "<<nested form>> (4.5.6) The form of a structure constructor for an
   entity of extended type in which a single value is provided for the
   <parent subobject> instead of separate values for each inherited
   component."

??ENDIF

[404:28+] Insert new entry
  "<<parent subobject>> (4.5.3.1) The subobject of an entity of extended
   type which corresponds to its inherited portion."

[406:36+] Insert new entry
  "<<subobject name>> (4.5.3.1) The name of a <subobject> of an entity;
   either a <component> name or a <parent subobject> name."

=== END