Re: optional arguments in subroutine or using generic procedure


Richard E Maine wrote:
Mike <acout@xxxxxxx> wrote:

I want to write a subroutine with flexible numbers of arguments. One
of the argument 'ID' will decide how many arguments this subroutine
would have. If ID=1, fewer arguments. If ID=2, add many additional
arguments. I am pondering if I have to write two subroutines with
different names and using generic procedure, or I write only one
subroutine with optional arguments declared. Currently, I've chosen
using generic procedure. However, it doesn't seem beneficially enough,
but only with length interface and a generic name only. So why use
generic procedure?

I'll note that having exactly 2 possibilities isn't what I'd label as
very "flexible". I suppose it is more flexible than having only one.

Seems to me like either way could work. I'd say it was mostly a matter
of which was more convenient, clear, etc. Factors to consider include
the following.

How much of the code is really common to both cases? This would affect
whether I'd consider it more convenient to have 2 separate routines or
one routine with a minor variation controlled by the arguments.

How logically related are the two routines? This would affect whether I
would consider it more clear to consider them as variants of one routine
or as two separate ones.

Is there a real reason why the two variants have to have the same name?
If you are calling them with different numbers of arguments, then that
distinction must be made when writing the code, so I'd think one could
about as conveniently just have two different, but possibly similar,
subroutine names.

Basically, all the generic option does is add the feature of being able
to call the two routines by the same name if you have written them as
two separate routines. Frankly, I tend to think that is a negative
rather than a positive in most cases. Why not just use the two names and
make it obvious which one is called? With different numbers of
arguments, it isn't as though using the same name will help portability
or anything concrete that I can see. In my opinion, generics are good
for things that are really very much the same operation applied to
different types. The intrinsics, such as sqrt, are prime examples. In
those cases, the generic helps portability (when porting involves a KIND
change). I think generics like the intrinsic ones also help clarity by
avoiding irrelevant distractions; you don't need to get distracted by
thinking of there being multiple versions of sqrt. But if the different
specifics in a generic have different numbers of arguments, then you
pretty much *HAVE* to think about which one you are calling when you
write the code, so I don't see the benefit of "disguising" the
difference by using the same name.

But that's just my personal take on generics; I think that some people
overuse them. Others might argue that I underuse them. :-)

Depending on various things, including the above factors, another
possibility to consider might be to have two separate routines, one of
which calls the other, or both of which call a 3rd one for the portions
that they share.

All these are just aspects to consider in terms of what will give the
best clarity and convenience. I don't see a definitive answer on one
"right" way.

--
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
Thank you, Richard.
According to your explanation, I have an feeling (generally not so
precisely) of :
(1) using generic procedure only in subroutines/functions with same
numbers of arguments
(2) if generic procedure is one's must, try to use derived type to
force the numbers of arguments to be the same. This one is the
afterthoughts from the above messages from Paul, I think if I don't
misunderstand it.
Thanks also go to Paulv.
Mike.

.

Relevant Pages

  • Re: optional arguments in subroutine or using generic procedure
    ... subroutine with optional arguments declared. ... How logically related are the two routines? ... two separate routines. ... I think generics like the intrinsic ones also help clarity by ...
    (comp.lang.fortran)
  • Re: Does F90 do type checking when calling module subroutines?
    ... I haven't yet seen a compiler that doesn't do it. ... > I have a subroutine defined in a module like this: ... interface block does is make a generic with this as one specific. ... makes generics. ...
    (comp.lang.fortran)
  • Re: modifying constants
    ... >>the subroutine expects, such as with a MODULE, will it convert ... > mistake, it just did something with them anyway. ... Binary constants for binary ... You mean generics for intrinsic functions? ...
    (comp.lang.fortran)
  • Question regarding generics and type constraints
    ... I'm new to Generics (years and years of VS.NET 2003 development, ... I have some routines for conversion from RGB to different ... color spaces and back. ... on Type Parameters" stuff using "where" in MSDN, but I'm not sure how I can ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: generic module procedures with function arguments
    ... Subject: Subroutine/function ambiguity in generics ... KEYWORDS: subroutine, generic, implicit ... It is in the end necessary that a function name be passed to a routine calling a function, and subroutine name passed to a routine calling a subroutine, but the generated code for the routine passing the name can be the same, which is usually passing the address of the routine. ...
    (comp.lang.fortran)