(j3.2006) Parent component of extension of abstract type

[Van Snyder]

On Thu, 2015-11-12 at 22:31 +0000, Bill Long wrote:
> On Nov 12, 2015, at 4:20 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> > On Thu, 2015-11-12 at 22:13 +0000, Bill Long wrote:
> >> On Nov 12, 2015, at 3:32 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> >> 
> >>> It seems a bit strange that I can't access the parent component of an
> >>> object of a type that is an extension of an abstract type, but I can
> >>> access components of the parent component.  Is this what we intended?
> >> 
> >> You?re not allowed to declare an object of an abstract type.  So it
> >> would seem odd to allow a designator for an object of an abstract
> >> type. 
> > 
> > According to the definition of type extension, an extension of an
> > abstract type has a component of abstract type.  But it can't be
> > accessed as a whole.  But its components can be accessed even if its
> > name appears in the <data-ref>.
> 
> But those components are not of abstract type, so it seems ok. 
> 
> > 
> > Maybe we should allow to instantiate nonpolymorphic objects of abstract
> > type, but prohibit invoking deferred type-bound procedures using one as
> > the <data-ref>.
> 
> Deferred usually means ?doesn?t exist yet?.   So, I agree that invoking a deferred tbp is a not a good idea. 
> 
> If you want to instantiate objects of the abstract type, just don?t make the type abstract. 

I don't want to instantiate objects of the abstract type, but I do want
to access the parent components of extensions of the type.  When I
create an object of an extension type, I want to copy default values
from the parent component of another object, and then fill additional
components in the new object.  The defaults aren't compile-time
defaults.  I can't copy the entire object that has my default values in
its parent component if the new object is not of the same type.

Copying the components of the parent type one at a time is tedious.  If
I don't copy them in the same order as the processor has decided it
wants to store them, the optimizer might not figure out that it can use
a "block transfer" instruction instead of a bunch of loads and stores.

> Cheers,
> Bill
> 
> 
> 
> > 
> >> Cheers,
> >> Bill
> >> 
> >>> 
> >>> program P
> >>> 
> >>> type, abstract :: T0
> >>>   integer :: N = 42
> >>> end type T0
> >>> 
> >>> type, extends(t0) :: T1
> >>> end type T1
> >>> 
> >>> type(t1) :: V1, V2
> >>> 
> >>> print '(a,i0)', 'V1 ', v1
> >>> print '(a,i0)', 'V1%T0 ', v1%t0      ! Prohibited
> >>> print '(a,i0)', 'V1%T0%n ', v1%t0%n
> >>> 
> >>> v2 = v1
> >>> v2%t0 = v1%t0                        ! Prohibited
> >>> v2%t0%n = v1%t0%n
> >>> 
> >>> end program P
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 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
> >> 
> >> 
> > 
> > 
> > _______________________________________________
> > 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
> 
>