Prev: intrinsic function optional argument
Next: Exact type redeclaration: standards conforming?
From: Richard Maine on 26 Feb 2010 12:51
Dave Allured <nospom(a)nospom.com> wrote:

> This is a terminology problem.

Ok.

> I coined the term "module interface" as a shortcut, thinking that it would
> be universally understood.

Might be if it weren't so close to "explicit interface", which in turn
is closely enough related to make some people (well, me anyway :-))
think that's what you mean.

> What I meant was adding a module-like
> wrapper or encapsulation around an older fortran library which includes
> external subroutines, external functions, and numeric constants.

You can't have numeric constants in an old Fortran library, though
perhaps you mean constants that are related to the library, even though
they aren't literally included in it. That aside...

> Objectives are better interface checking and eliminating preprocessor
> kludges. I imagine that this must be a regular occurrence in the world
> of public software.

Good objectives and yes, it is common. I think the standard might even
give something like that as an example (not worth checking). Certainly
I've seen it several places.

> In short, I wanted to add some interface blocks and call it a module,
> albeit imperfect as per (2) and (3). Do you have a concise term for
> such an encapsulation?

Not a particular one that I recall, but I think your description above
is pretty good and probably has something that a shoprt form can be
extracted from. You refer to a "module-like wrapper". I think we can
just drop the "like" part, as it is actually a module. That leaves
"module wrapper", which seems like a good term for it to me. I might
have even used that term myself, as it seems fairly natural.

I'd avoid calling it a "module encapsulation", as that has slightly
different implications, at least to my ear. To me, a module
encapsulation would sound like actually putting the routines into a
module, which can also be done, but not for a pre-compiled library such
as you are talking about. In ordinary English, "wrapper" might have a
similar connotation (if you wrap something then it is inside of the
wrapper), but the computer usage of "wrapper" doesn't necessarily have
that same implication. Anyway, one hears people talking about wrappers
all the time without meaning that.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 26 Feb 2010 13:12
Richard Maine <nospam(a)see.signature> wrote:

> Dave Allured <nospom(a)nospom.com> wrote:

> > What I meant was adding a module-like
> > wrapper or encapsulation around an older fortran library...
> > Objectives are better interface checking and eliminating preprocessor
> > kludges. I imagine that this must be a regular occurrence in the world
> > of public software.
>
> Good objectives and yes, it is common.

I might add that a simillar thing I have done fairly often is to add
such a wrapper around C libraries. Prior to f2003, this required 2
layers of wrapping, one compiler-dependent layer in C and one layer in
Fortran. The C layer was to make wrapper routines that were Fortran
callable at all; that would handle any required name mangling, plus
conversion of call-by-value arguments. The Fortran layer added explicit
interfaces and related constants. With the f2003 C interop stuff, those
two layers can be combined into one and the compiler dependence avoided.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Pierre Asselin on 27 Feb 2010 13:47
Richard Maine <nospam(a)see.signature> wrote:

> [ ... ] That leaves
> "module wrapper", which seems like a good term for it to me.

How about "wrapper module" ? After all, it is the module
that does the wrapping, not the other way around.

--
pa at panix dot com
From: Dave Allured on 3 Mar 2010 15:03
Followup. With your advice, I made a complete Fortran 90 "module
interface" for the UDUNITS-1 units conversion library package from
Unidata. The original Fortran 77 style interface presents subroutines,
functions, and numeric "parameters" via an include file. Under the
hood, it is all C routines with a cfortran interface for F77.

It worked like a charm. I was able to neatly embed everything into a
single module without any name munging. So by just replacing an include
statement with "use udunits" in application routines, one gets the
benefit of interface checking, as well as a fix for an awkward
preprocessor requirement for a special data type.

Personally, I had to get over my prejudice against interface blocks and
learn how and when to use them correctly.

Thanks to Jim, fj, and Richard for your good advice.

--Dave
First  |  Prev  | 
Pages: 1 2 3
Prev: intrinsic function optional argument
Next: Exact type redeclaration: standards conforming?