Re: optional arguments in subroutine or using generic procedure
- From: nospam@xxxxxxxxxxxxx (Richard E Maine)
- Date: Thu, 13 Jul 2006 08:33:54 -0700
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
.
- Follow-Ups:
- References:
- Prev by Date: Re: optional arguments in subroutine or using generic procedure
- Next by Date: Re: Initialisation of multidimensional array
- Previous by thread: Re: optional arguments in subroutine or using generic procedure
- Next by thread: Re: optional arguments in subroutine or using generic procedure
- Index(es):
Relevant Pages
|
|
