Re: Multiple Classes per File and use
- From: Uri Guttman <uri@xxxxxxxxxxxxxxx>
- Date: Wed, 07 Feb 2007 15:51:57 -0500
"XC" == Xiong Changnian <please@xxxxxxxxxx> writes:
XC> But if I can use Jam::Band and use base Jam::Band if I package
XC> Jam::Band, then I will sleep better. Thanks.
XC> In article <x7k5yw9reh.fsf@xxxxxxxxxxxxxxxx>,
XC> Uri Guttman <uri@xxxxxxxxxxxxxxx> wrote:
>> use named variable when possible.
>> it makes for more easily understood code.
XC> Sorry, I haven't the faintest idea what you're driving at, unless you're
XC> already talking about the symref -- and that comes in the next line.
XC> Maybe you just want me to deref to a temp variable before proceeding.
XC> I'm content to jam it all in one line.
you used a for loop with the implied use of $_ as the loop variable. it
is better to use a named lexical variable instead like this:
for my $foo ( @bars ) {
it makes the code easier to understand since the loop body will have
that name to help document it. i only use $_ in map/grep where it is
required and in special cases where it works better.
XC> I'm from the days when absolutely everything had to be declared and
XC> reserved; every single operation was one instruction at a time.
XC> Sometimes one machine-language instruction actually ran to more than one
XC> line of code.
you don't have to tell us your background regarding declarations. most
of the regulars here know multiple langs and know all about this area.
XC> When I iterate over an array without knowing, anywhere, the loop
XC> iterator even exists I get a little woody. :P You see the verbose
XC> version of my code. Yes, I know, it's a sin. Sorry.
but you didn't use an explicit loop iterator variable but the default
$_.
XC> &{"report_" . lc($_)} ($ref->{SETS}{$_})
>> ...make a dispatch table...
XC> Oooh, sorry, but I sort of disagree. Maybe better than blatantly
XC> constructing the sub name out of sticks and pebbles on the fly but a
XC> jump table is a jump table, no matter what you call it. I'm looking for
XC> more elegance.
XC> "calculated jump". As I posted, that's the first thing to break. Last
XC> time I tried that for a client on a serious project, was 20 years ago
XC> and I thought I was cool. I only did it because it could be done -- and
XC> because nobody had ever educated me as to why it might be risky.
this is very wrong in several ways. it is a symref which you said you
don't want to do and no one recommends that you do. it is not testing if
the sub exists or not. it is a potential source of future bugs (all
synrefs are). it uses the symbol table as a general purpose hash when it
should be only used to mung the symbols. you can make the dispatch table
a lexical hash whics is safer (more private) and you can pass it around
or store it in something else like an object (can't be done with symrefs
since they are global). so there are many reasons to use a dispatch
table and none that support using symrefs there. you asked for advice on
coding and this is one answer you shouldn't ignore regardless of your
taste and style. it is BAD coding to use symrefs if there is a better
way to do it. that is why use strict disallows them.
uri
--
Uri Guttman ------ uri@xxxxxxxxxxxxxxx -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
.
- References:
- OO Perl Online Learning
- From: Xiong Changnian
- Re: OO Perl Online Learning
- From: xhoster
- Multiple Classes per File and use (was: OO Perl...)
- From: Xiong Changnian
- Re: Multiple Classes per File and use (was: OO Perl...)
- From: xhoster
- Re: Multiple Classes per File and use (was: OO Perl...)
- From: Xiong Changnian
- OO Perl Online Learning
- Prev by Date: FAQ 4.14 How can I compare two dates and find the difference?
- Next by Date: Re: how to forward an array to another cgi?
- Previous by thread: Re: Multiple Classes per File...
- Next by thread: Re: Multiple Classes per File and use
- Index(es):
Relevant Pages
|
