Uri Guttman wrote:
>> "SB" == Steve Bertrand writes:
>
> SB> I have found some benefit to having wildly changing API's... I've learnt
> SB> better ways to manage the callers to minimize impact, and better ways to
> SB> design parameter handling. I'm sure once I find my own style that
>
> "SB" == Steve Bertrand writes:
SB> I have found some benefit to having wildly changing API's... I've learnt
SB> better ways to manage the callers to minimize impact, and better ways to
SB> design parameter handling. I'm sure once I find my own style that
SB> conforms (even loosely)
David Christensen wrote:
> Steve Bertrand wrote:
>> My question is, is if it is common practise to use named parameters
>> for incoming arguments to functions/methods.
>
> I tend to code for personal, private use, so I have the luxury of
> changing my mind as the mood suits me. I once saw a book
On Sat, Jul 18, 2009 at 21:54, David
Christensen wrote:
> Steve Bertrand wrote:
>> I've been reading both the Cookbook and HOP
>
> HOP?
snip
Higher Order Perl: http://hop.perl.plover.com
--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
--
To unsu
Steve Bertrand wrote:
> I've been reading both the Cookbook and HOP
HOP?
> My question is, is if it is common practise to use named parameters
> for incoming arguments to functions/methods.
I tend to code for personal, private use, so I have the luxury of
changing my mind as the mood suits me.
> "SB" == Steve Bertrand 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.
Thanks to all of the on, and off-list feedback I've received over the
last month, I've realized I've been missing out on quite a bit.
I tend to read past the finer points that people refer to. For
instance... dispatch tables. It is hard for me to wrap my head around
how immensely useful such subtl
