Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

question on polymorphism


Fortran comrades:

        In my Fortran 95 program I have the following two types:

In module ProfileTyp, public type:

TYPE :: TProfileData
   REAL (DP) :: Cv = 0.0_DP, CC = 0.0_DP, NominalClAp = 0.0_DP
END TYPE TProfileData

and in module AspDatTyp (which uses ProfileTyp):

TYPE :: TAspData
   TYPE (TProfileData) :: Profiles (2, NO_OF_WAVELENGTHS)
   INTEGER (DI) :: NType = 0
   ! more components
END TYPE TAspData

where DP, DI and NO_OF_WAVELENGTHS are INTEGER PARAMETERS available via
USE association of other modules (not shown here).

        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.) Perhaps someone with some
good experience with C++ can help. Or is this a case where I have a "has
a" relationship, not an "is a" one?

Norm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Norman,

 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
  :
END TYPE

 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) ,....
 END TYPE

  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)
  END TYPE

  could be introduced as a base type, but then you still need to
  write wrappers for all methods operating on arrays of type
  TProfileData.

Regards

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGSV1JFVLhKuD7VgsRAipmAKCA0lU3uaqYWshtCjccdoNKO1t15ACfXqzU
OIeICJV+7o2ErEOeg0yTho0=
=guRS
-----END PGP SIGNATURE-----

Norman S. Clerman wrote:
> 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.)

I'm not sure I really understand what you're trying to achieve, but if
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"
true?
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".

--
     -+-Ben-+-

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc