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

Van Snyder Van.Snyder
Thu Nov 12 20:54:44 EST 2015

On Fri, 2015-11-13 at 09:56 +0900, Cohen Malcolm wrote:
> >Maybe we should allow to instantiate nonpolymorphic objects of abstract
> >type,
> Not being able to instantiate objects is a fundamental point of abstract 
> types.  If you can instantiate them, the whole abstract edifice falls to the 
> ground - there can be no compiler protection against mistakes (that being 
> the only reason it was worth adding abstract types in the first place).  If 
> abstract were limited to a gentle reminder that you're supposed to do 
> something with the deferred type-bound procedures when extending, it would 
> not have been anywhere near valuable enough to be an actual language 
> feature.
> If you need to instantiate them, then just don't make it abstract.  It's as 
> simple as that.

There seems not to be a problem with instantiating objects of abstract
type, so long as one does not try to use the object to invoke deferred
type-bound procedures, or use it as the target of a pointer assignment,
or the source or mold in an allocation if the <allocate-object> is
polymorphic.  Trying to do that ought to produce a hard error message,
not a gentle reminder that it's problematic.  If one extends an abstract
type and doesn't add any components, objects of the extension type are
essentially instantiations of the abstract type, which has a
nonpolymorphic component (its parent component) of abstract type.  One
is not permitted, however, to declare a (nonpolymorphic) component of
abstract type.  The dangerous situation occurs when a polymorphic object
has an abstract dynamic type, which we have successfully prohibited with
a really large hammer.  But....

The question wasn't about instantiating objects of abstract type.  It
was about accessing the parent component of an object whose type is an
extension of an abstract type.

The whole object can be referenced, or components of the parent
component can be referenced, but the parent component itself cannot be

If I create an object of a type that is an extension of an abstract
type, and I want to fill its parent component with the same values as
the parent component of another object (which might not have the same
dynamic type), I cannot copy the parent component en masse.  I must copy
it component-by-component.  This is tedious if the parent type has more
than a few components.  If I don't copy the components in the same order
that the processor has decided to arrange them, its optimizer might not
realize it can copy them with a "block transfer" instruction instead of
a bunch of loads and stores.

> Cheers,

More information about the J3 mailing list