Bioperl: Re: Style Q for modules: best syntax for "hash" arguments?

[Steve A. Chervitz]

Jim Stern wrote:

> Eryq wrote:
> >
> > Since this question relates to style considerations for
> > authoring reusable modules, I've posted in c.l.p.modules
> > as well...
> >
> > Oftimes, we see subs which take arguments in a hash form,
> > like this [1]:
> >
> >         foo(ThisThing => $this,
> >             ThatThing => $that);
> >
> > Sometimes, we see this instead [2]:
> >
> >         foo(-this_thing => $this,
> >             -that_thing => $that);
> >
> > And even [3]:
> >
> >         foo(THIS_THING => $this);
> >
> > Not to mention some which do extra work to case-fold
> > arguments and chop leading '-'s off, so that you
> > can supply args in more than one style.
> >
> > So: are we at all moving towards a Perl style standard for
> > this... and if so, what is it?  Although I've been doing [1]
> > for years, I've gradually warmed on [2].  And [3] looks
> > too... um... "loud".
>
> I can't say what the consensus is but to me the dashes just
> add clutter.  Since Perl5.000 we've had '=>' as a kind of comma
> that quotes its left operand.  With '=>' you need no leading dash
> so why have one?

When a function can accept either named or unnamed parameters, it would
be nice to have a standard mechanism for discriminating these cases. For
example, it's convenient to allow the following:

     new->Foo("MyFoo");                # Gets default settings.
     new->Foo(-name   => "MyFoo",      # Custom settings.
              -flavor => "vanilla");

If named parameters always start with a "-" then it is easy to
distinguish these situations, regardless what case is used for the tags.

As far as case goes, I'm currently favoring -ALL_CAPS since (1) it
avoids conflicts with function names (typically all lower case, but
watch out for DESTROY) and thus saves you from having to explicitly
quote all the tags, (2) parameter settings stand out better in the code
(take this paragraph, for example), and (3) it seems consistent with the
Perl-ism that things in ALL_CAPS are things that are defined for you.

Until perl gets better at not confusing "-name =>" and "-&name =>"
within argument lists (maybe this is unreasonable to expect?), I'm
sticking with -NAME style tags. One thing I have noticed, though, is
that my own style preferences evolve with time, especially as I learn
from other people's styles. I do however strive for internal consistency
at any given point in time.

Steve Chervitz
sac@genome.stanford.edu

P.S. What might be nice is a standard GetOptions::Long sort of
functionality at the function call level. I worry about incurring
additional method call overhead, but the added flexibility may be worth
it in some situations.

>
>
> Of course, if a keyword matches a sub name or a predefined name,
> you still have to enclose it in quotes to avoid a -w warning.
> But in my experience, that's rare.
>
> And I agree.  [3] is like a drill sergeant screaming, inches
> from your face.  :-)
>
> Just one opinion ...
>
> > [...]
> >
> > However, it might be nice to have perlstyle guidelines for
> > when there is "no good excuse to do otherwise".
>
> But isn't there always "More Than One Way to Do It?"  :-)
>
> --
> Jim Stern -- Views here are my own, not Northrop Grumman's.   (El
> Segundo, CA)



=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================