(j3.2006) Types need a "self" component

Van Snyder Van.Snyder
Thu Dec 17 22:29:06 EST 2015


It's not possible to assign to a nonallocatable polymorphic object, or
to the declared-type part of it, without mentioning all the components
of the declared type individually, even if the class is not abstract.

If a type had a nonpolymorphic "self" component of the same name and
type as itself, encompassing all its components in the same way a parent
component encompasses all its components, it would be possible to assign
to the declared-type part of a polymorphic object, without mentioning
all the components individually.

type :: T1
  integer :: A
  integer :: B
  ...
  integer :: Z
end type T1

class(t1) :: V1
type(t1) :: V2

v1 = v2    ! prohibited
v1%t1 = v2 ! would be nice, but we didn't do it

! This is what appears to be necessary:
v1%a = v2%a
v1%b = v2%b
...
v1%z = v2%z

Here is an ugly workaround:

type :: T0 ! Cannot be abstract if you want it to be useful
  integer :: A
  integer :: B
  ...
  integer :: Z
end type T0

type, extends(t0) :: T1
end type T1

class(t1) :: V1
type(t1) :: V2

v1%t0 = v2%t0

An even uglier workaround, involving another level of the type
hierarchy, is needed if the base type is abstract,

! Please tell me I'm wrong, and show me a work-around that doesn't
! involve another level of the type hierarchy.

Other extensions I've proposed earlier, to allow referencing components
of abstract type except for using them to invoke deferred type-bound
procedures, would be necessary to complete the usefulness of the "self"
component if the "self" type is abstract.

An elaboration of the mechanism proposed as "Alternative Proposal #2" in
15-166 would also solve the problem.  The elaboration would be that if
the dynamic type of the LHS is an extension of the dynamic type of the
RHS, only the part of the LHS that is of the same type as the dynamic
type of the RHS is filled, the <stat-variable> is set to a warning
value, and an error does not occur.





More information about the J3 mailing list