(j3.2006) I think this is possible, but....

[Van Snyder]

On Tue, 2018-01-23 at 14:19 -0800, Damian Rouson wrote:
> =
> 
> On January 23, 2018 at 2:07:39 PM, Clune, Thomas L. (GSFC-6101)
> (thomas.l.clune at nasa.gov) wrote:
> 
> > 
> > Van, 
> > 
> > Note - I?ve not read this carefully, but this my immediate response
> > is that this is _not_ something you should be able to do with type
> > extension. 
> Yes and no.  I wouldn?t recommend type extension in the manner
> described in the original email, but I wonder whether it?s a case in
> which the component itself should be polymorphic and a setter
> subroutine can be invoked to establish the dynamic type, thereby
> allowing the information that the component stores to vary as the
> component?s dynamic type varies.

The problem with using a polymorphic component is that all you can see,
even in an extension of the type that contains it, is the declared type,
until you "pop it open" using a SELECT TYPE construct.

> > Instead, it appears to be a classic example of the need for generic
> > programming. 
> or possibly a classic setting in which object-oriented design patterns
> would be useful.  My recommendation above is essentially an example of
> the State pattern.  In a paper we published in Scientific Programming,
> Salvatore and I applied the State pattern to allow the storage format
> used in a sparse-matrix library to vary at runtime based on the
> problem and hardware available.
>  See https://www.hindawi.com/journals/sp/2014/469753/abs/.

I'm inclined to agree with Tom that generic programming might be a
better solution.  It doesn't require strenuous gymnastics to look at the
components of an extension of the declared type, and doesn't impose a
runtime penalty by requiring a descriptor to look at its components.

My original proposal for parameterized modules advocated to allow data
objects, types, procedures, and modules as parameters -- of course
prohibiting circularity.  That got reduced to integers, and then
rejected.  Types as type parameters have been discussed briefly, and
then dismissed.

> Damian