After Tom and I had a discussion off this mailing list about his
project, I realize I should clarify something I wrote in my earlier
message.
He wrote:
> >> If none of the scientists had ever ventured beyond F77, then
> >> the solution would be to write the framework in C++ and call
> >> F77 routines as needed. However, many scientists have started
> >> using various F90 extensions which introduce _nontrivial_
> >> inter-language issues. (E.g. how to pass the dope vector for
> >> F90 arrays.)
> >>
> >> I see 4 solutions.
> >>
> >> 1) Rewrite any necessary F90 code in C++. Some scientists will
> >> probably resist this to the point that the project will fail.
> >> On the plus side, we could hire some new software engineers
> >> that would otherwise be unwilling to work in Fortran. (Begging
> >> the question of whether NASA can afford to hire C++ software
> >> engineers ...)
> >>
> >> 2) Wait for F2k compilers to be released (and stable). F2k
> >> provides almost everything that is needed to develop a
> >> framework. However, we cannot wait that long, and it is very
> >> difficult to find software engineers that will work in any
> >> variant of Fortran..
I wrote:
>
> Jing> Although these two solutions are often mentioned, I wonder
> Jing> if anyone would consider them practical.
>
He wrote:
> Certainly some people must consider waiting for F2k to be practical,
> or else why is anyone bothering to work toward creating such a
> standard?
I wish I have said ".. consider them practical for an on-going project".
I certainly consider the F2K standard activity to be the most important
source of guidance for software design activities.
I wrote:
>
> Jing> First, I strongly believe that a robust mixed language
> Jing> environment is essential for the developments of today's or
> Jing> tomorrow's complicate scientific computing systems. This is
> Jing> really not by choice but by reality.
>
> Jing> Having said that, I don't think this mixed language
> Jing> environment must be general (or even possible to be so).
> Jing> This environment may be implementable only if some
> Jing> constraints are enforced. For example, I believe following
> Jing> constraints would be helpful:
>
> Jing> o A software "module" (not a Fortran MODULE) should be
> Jing> developed in the same language, with interfaces to other
> Jing> "modules" that may be written in other languages. This
> Jing> often naturally happens.
>
> Jing> o A software "module" should have very strong encapsulation.
> Jing> This also often naturally happens if the "module" is
> Jing> identified properly.
>
> Jing> Two constraints above will allow the interface of this
> Jing> "module" with the outside world (e.g. C or C++ or Fortran)
> Jing> to be minimized. I think this is a very important initial
> Jing> condition. If one can not define a small set of practical,
> Jing> stable, yet extendible, Fortran 90 interfaces for a given
> Jing> "module" (or make it a "class"), there is little reason to
> Jing> go any further.
>
Tom wrote:
> But you do not get inheritance this way. The "powers-that-be" have
> essentially dictated that the nature of frameworks contains
> inheritance of abstract base classes. Thus, the handle would
> in principle allow you to participate in the framework, but you'd
> probably lose most of the value.
I realized I had a wrong impression that his project requires an
integrated system with both C++ and Fortran components. My
understanding now is that his objective is to emulate an _inheritance_
mechanism with Fortran, similar to what F2K may have designed to do
(What was I thinking? It was the title of this thread!). My approach
would be pushing _inheritance_ issue away from Fortran, but let C++
(through implicit interface in FORTRAN/C) to deal with it.
Most of my concern for any Fortran emulation approach for _inheritance_
is not their syntactic solutions but their system engineering aspects.
One important difference between true _inheritance_ and some of its
emulations is that they often have reverted dependency relations between
a generic type (EXTENSIBLE?) and the types EXTENDS it.
For example, if an E-type "is a" G-type, as _inheritance_, one would
have an E-type depending on the G-type at the compilation time. As an
emulation, however, one may end up with the G-type (or its variation)
depending on all E-types for compilation. Given my limited knowledge
about OO, this seems to be because many emulations use _composition_ to
emulate _inheritance_.
IMHO, this reverted relationship in a given emulation would be a quite
restrictive constraint on its usefulness for many potential system
applications.
Jing
> --
> Thomas Clune, Ph.D. Parallel Applications Consultant
> SGI [log in to unmask]
> Code 931 NASA GSFC 301-286-4635 (work)
> Greenbelt, MD 20771 301-286-1634 (fax)
>
--
________________________________ _-__-_-_ _-___---
Jing Guo, [log in to unmask], (301)614-6172(o), (301)614-6297(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|