-----BEGIN PGP SIGNED MESSAGE-----
Since most compilers support TR15581, you could shift the array
property to the components of TProfileData and extend from there:
TYPE :: TProfileData
REAL (DP), allocatable, dimension(:,:) :: Cv, CC, NominalClAp
END TYPE TProfileData
TYPE, extends(TProfileData) :: TAspData
integer(DI) :: NType = 0
The allocation itself would need to take care of initialization.
More elegantly, type parameters could be used:
TYPE :: TProfileData(n,m)
integer, len :: n, m
real(DP) :: Cv(n,m) ,....
but to my knowledge no compiler supports this feature yet.
Both solutions have the disadvantage that all code involving
objects of the base type needs to be changed
(foo(k,i)%cv --> foo%cv(k,i) etc.)
If this is too much work,
TYPE :: TProfileDataArray
type(TProfileData) :: Profiles (2, NO_OF_WAVELENGTHS)
could be introduced as a base type, but then you still need to
write wrappers for all methods operating on arrays of type
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Norman S. Clerman wrote: I'm not sure I really understand what you're trying to achieve, but if
> TYPE :: TAspData
> TYPE (TProfileData) :: Profiles (2, NO_OF_WAVELENGTHS)
> INTEGER (DI) :: NType = 0
> ! more components
> END TYPE TAspData
> I'd like to use Fortran 2003 extensible types and have TYPE TAspData
> EXTEND TYPE TProfileData. Is there any way I can do this? (This wouldn't
> be a problem if Profiles weren't an array.)
you want to have individual sets of those "more components" associated
with EACH and every of the TProfileData elements you have, then just
stuff those into the TProfileData type itself. Alternatively, you can
extend just a single element of TProfileData, then make an array of
TAspData instead. That might not be what you really need though...
> Or is this a case where I have a "has a" relationship, not an "is a" one? That's a question you can probably better answer yourself. Is the statement
"A TAspData is a TProfileData"
Maybe you can also conclude that:
"A TProfileData is not necessarily a TAspData"
In the above statements, please also note the "a" articles; we're
generally considering single instances of things in that judgement.
(Which doesn't prevent us from having as many as we like later; we're
merely considering the relationship between those two classes of objects.)
If the above statements can both be concluded to be true, then the Right
Solution [tm] is probably something along the lines of what you
suggested. However, to be a bit nitpicking, that is not exactly
polymorphism. It's actually inheritage. ;-)
My first thought was that your problem actually seemed more like a "has
a" relationship, so maybe that fits your problem better. Try a few
claims with "has a" or "has a set of" to see whether that "fits the bill".