>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes:
SB> I tend to read past the finer points that people refer to. For
SB> instance... dispatch tables. It is hard for me to wrap my head around
SB> how immensely useful such subtle things can be!
dispatch tables are very easy in perl and extremely useful. too bad more
newbies take forever to learn them.
SB> For instance... even though most of my code is object oriented, I feel
SB> that there are huge advantages to allowing subs to be passed in as
SB> arguments (to nearly all methods). As soon as I realized but a subset of
SB> potential the dispatch table has, I know I can command and control my
SB> entire project from one spot if the argument handling is done properly.
SB> My question is, is if it is common practise to use named parameters for
SB> incoming arguments to functions/methods. Whether it is or isn't common
SB> practise, is it recommended that a project should keep consistent with
SB> ALL methods/functions in this regard whichever way one decides?
a good rule of thumb is for 3-4 args or less, use basic arguments. don't
use shift but assign them to a list of scalars:
my( $foo, $bar, @rest ) = @_ ;
SB> I'm tired of trying to pop/shift error check the way I have been. It's a
SB> nightmare when I want to add a new argument to an API, as it immediately
SB> causes great (oftentimes subtle) havoc until I fix all of the callers.
that is fine when the api is small and unlikely to ever change. there
are a good number of subs that work fine like this. the key is whether
you will need to expand the api. that can break old code using the older
api. passing key/value args has several advantages. you can pass only
the arguments you want, you can easily add new args without breaking
older code and you can collect and pass around all the args in a single
hash ref too.
you need to do more thinking before you code. i like 40% thinking, 40%
coding and 20% (or less) debugging. too many coders (especially newbies)
do like 5% thinking 50% coding and 45% (or more) debugging. thinking is
much easier than debugging. if you can think about the future use of
your subs, then you can pick an api that can grow with it. this is where
a key/value api comes into play. but using that for all subs is just as
bad as some subs just need a single arg or a couple and should stay that
way forever. api design is all about thinking and not about coding at all.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
