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

[Bill Long]

On Dec 17, 2015, at 9:29 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

> 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

I thought that 

select type (V1)
type is (t1) 
   v1 = v2
class default
   v1%t1 = v2
end select

was designed to handle this type of problem. 

Cheers,
Bill





> 
> ! 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.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101