Re: interface blocks
- From: Richard E Maine <nospam@xxxxxxxxxxxxx>
- Date: Thu, 25 Aug 2005 09:39:40 -0700
In article <11grpkobec8rl5d@xxxxxxxxxxxxxxxxxx>,
"Lynn McGuire" <nospam@xxxxxxxxxx> wrote:
> I have about 3500 subroutines with 400,000 lines of f66/f77 that I am
> porting to use IVF 9.0. I am considering building a generic interface
> block with all 3500 subroutines in order to ensure that we are not
> having argument problems (number of and/or data type). I have been
> told that this might be a bad idea. Why ?
Um. I think you are confusing some terminology.. because that doesn't
even make sense.... at least not with the word "generic" in there. You
just mean an interface block rather than a generic one, right? An
interface block at least makes sense, but a generic one doesn't.
A generic interface block is one that defines multiple specific
procedures to be called using the same generic name. I seriously doubt
that you want all your 3500 procedures to be called with the same name.
Certainly would be one way to obfuscate the source code. :-) But the
odds are just about zero that all 3500 would meet the requirements for
being in the same generic anyway.
I just spent most of the last hour re-explaining to a J3 member why the
same horribly, horribly bad idea that he proposed a few years ago is
still just as completely unworkable now as it was then. (He thought it
was a trivial change, but failed to see how it affects things all over
the standard in incompatible ways). He had forgotten why it got shot
down then, so figured that must be good enough reason to try again. So
I'm about out of steam/patience for doing explanations of why things are
a bad idea right now. If I try, it will end up sounding curt, which
isn't actually justified.
The very short version, then. Perhaps others can expound.
I'd say not so much that doing interface bodies is a bad idea as that
doing other things (module procedures) is better. Interface bodies can
give you a false sense of security. To me, one of the big problems with
interface bodies is that they are usually *NOT* checked against the
actual procedure. You get checking that the call is compatible with the
interface body, but what you really wanted was checking that the call is
compatible with the procedure. Where before, you had only 2 places that
needed to be compatible (the call and the procedure), you now have 3
(the call, the procedure, and the interface body). In some ways, this
overstates the problem, because you only have one interface body per
procedure, while you presumably have multiple calls. Still, that's the
crux of the issue.
Oh, and there are various annoyances in terms of writing the interface
bodies correctly, but those are more annoyances than real reasons not to
do it. Most notable is the mess with interface bodies not getting host
association. In 99+% of the cases, that just means you have to remember
the extra trick. In a few special cases, it turns out to be quite hard
to do at all without a hack introduced in f2003. One is likely to just
give up on those instead.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.
- Follow-Ups:
- Re: interface blocks
- From: Lynn McGuire
- Re: interface blocks
- References:
- interface blocks
- From: Lynn McGuire
- interface blocks
- Prev by Date: Re: Acceptable Pack args
- Next by Date: Re: Acceptable Pack args
- Previous by thread: Re: interface blocks
- Next by thread: Re: interface blocks
- Index(es):
Relevant Pages
|
|
