[32726] in Perl-Users-Digest
Perl-Users Digest, Issue: 3990 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 15 09:09:33 2013
Date: Mon, 15 Jul 2013 06:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 15 Jul 2013 Volume: 11 Number: 3990
Today's topics:
[OT] engineering <oneingray@gmail.com>
Re: [OT] scoping <jblack@nospam.com>
Re: [OT] scoping <ben@morrow.me.uk>
Re: [OT] scoping <rvtol+usenet@xs4all.nl>
Re: [OT] scoping <ben@morrow.me.uk>
Re: [OT] scoping <rvtol+usenet@xs4all.nl>
Re: [OT] scoping (Tim McDaniel)
Re: [OT] scoping <rvtol+usenet@xs4all.nl>
Re: [OT] scoping <ben@morrow.me.uk>
Re: [OT] scoping <xhoster@gmail.com>
Re: [OT] scoping <rvtol+usenet@xs4all.nl>
Re: [OT] scoping <xhoster@gmail.com>
Re: [OT] scoping <jblack@nospam.com>
the fastest way to create a directory <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: this should work <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 15 Jul 2013 11:37:58 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [OT] engineering
Message-Id: <87mwpouk89.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>>> When people can't have multiple disjunct sets of variables used by
>>> unrelated parts of the same 'aggregate subroutine', they do what
>>> they should be doing instead, namely, structure their code.
>> I disagree. I deem the use of nested scopes as crucial to code
>> structuring. Should the "roles" of the variables (whether input,
>> output, or local) become apparent later, it'd be trivial to split
>> the function, -- and that's likely to be done exactly along the
>> scope boundaries previously coded in.
> To quote my boss: Make it work now quickly and clean it up later :-).
> Which means: Take some existing code which performs a more-or-less
> related task, copy'n'paste it to some part of the countryside where
> no trenches have been dug yet or the old ones worn out over time,
> create a new nested scope lest all hell breaks lose because any
> accidental interaction with the surrounings, any details about them
> long lost in the land of ancient lore,
[...]
... Once, I will find the patience to wait for the food
engineers out there to design a sound nutritional solution.
Meanwhile, I'm forced to rely on the off-the-shelf products,
which are known to be full of undocumented features, deviate
from the specifications every now and then, and (while I'm yet
to see one myself) are reported to contain actual bugs...
[Cross-posting to news:alt.food and news:comp.programming.
Just in case.]
--
FSF associate member #7257
------------------------------
Date: Sat, 13 Jul 2013 20:01:49 -0500
From: John Black <jblack@nospam.com>
Subject: Re: [OT] scoping
Message-Id: <MPG.2c4bb477956688ee989784@news.eternal-september.org>
In article <kk76ba-bv9.ln1@anubis.morrow.me.uk>, ben@morrow.me.uk says...
>
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> > On Fri, 12 Jul 2013 15:50:48 +0100, Rainer Weikusat wrote:
> >
> > > Again, the way to solve the problem that 'nobody can still find his way
> > > through this mess' is to avoid creating it in the first place: Don't
> > > separate 'declaration and use' of a variable by 'thousands of lines of
> > > code', move these 'thousands of lines' into subroutines which don't have
> > > to share state with some parent routine and pass the data they need to
> > > them as arguments.
> >
> > Although I agree that it is a bad idea, it is how Pascal was meant to be
> > used. In the mean time, we learned this was not the greatest of ideas,
> > and likewise, I think 'tight' scoping of variables is a very good idea.
>
> Rainer has a point, buried somewhere in the bluster, in that if a sub
> needs to be divided into two or more bare blocks in order to limit the
> scope of variables those blocks should probably be diked out into
> separate subs. I very rarely use bare blocks, and when I do it's usually
> for their loop properties (so that next/last/redo will work) rather than
> their scoping.
Ben, what is the meaning of a bare block? Trying to follow...
John Black
------------------------------
Date: Sun, 14 Jul 2013 03:24:16 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <gne9ba-k9p.ln1@anubis.morrow.me.uk>
Quoth John Black <jblack@nospam.com>:
> In article <kk76ba-bv9.ln1@anubis.morrow.me.uk>, ben@morrow.me.uk says...
> >
> > Rainer has a point, buried somewhere in the bluster, in that if a sub
> > needs to be divided into two or more bare blocks in order to limit the
> > scope of variables those blocks should probably be diked out into
> > separate subs. I very rarely use bare blocks, and when I do it's usually
> > for their loop properties (so that next/last/redo will work) rather than
> > their scoping.
>
> Ben, what is the meaning of a bare block? Trying to follow...
A block like this:
{
my $x = ...;
}
with no other control structure attached. They can be used to limit the
scope of a variable to something smaller than a sub; in Perl they are
also one-iteration loops, meaning that the loop control operators (next,
last, redo) and the loop-naming syntax will work on them.
[Strictly speaking the 'barest' form of block in Perl is the do {}
block, which, like the block form of 'if', is just a scope without any
loop semantics. However, it's very rare to see anyone use do {} for
scoping, partly because it looks weird and partly because do is an
expression and so requires a trailing semicolon, like eval {}.]
Ben
------------------------------
Date: Sun, 14 Jul 2013 10:49:19 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: [OT] scoping
Message-Id: <51e2660f$0$15864$e4fe514c@news2.news.xs4all.nl>
On 14/07/2013 04:24, Ben Morrow wrote:
> However, it's very rare to see anyone use do {} for
> scoping
Often used in "libary" code here, like:
my $sql_stmt = do {
local $" = q{,};
qq{
SELECT
$columns_csv
FROM
$table
WHERE
id IN (@ids) -- hundreds easily
AND
$and_where
};
};
We also have quite some occurences of
eval { ... } or do { my ...; ... };
The worst are the do-blocks of many hundreds of lines.
They tend to keep growing, and prove hard to get rid of.
--
Ruud
------------------------------
Date: Sun, 14 Jul 2013 13:13:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <i7haba-e8u.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> On 14/07/2013 04:24, Ben Morrow wrote:
>
> > However, it's very rare to see anyone use do {} for
> > scoping
>
> Often used in "libary" code here, like:
>
> my $sql_stmt = do {
I was unclear. What I meant was, if you just want a simple variable-
scope-limiting block, the cheapest way to do that is with a do block (in
void context).
Using do to turn a block into an expression is what it was meant for, of
course.
> local $" = q{,};
>
> qq{
> SELECT
> $columns_csv
> FROM
> $table
> WHERE
> id IN (@ids) -- hundreds easily
Please, someone tell your cow-orkers about placeholders...
> AND
> $and_where
> };
> };
>
>
> We also have quite some occurences of
> eval { ... } or do { my ...; ... };
Well, the difference between
if (...) {...}
and
... and do {...};
is minimal. They compile to the same optree, the only difference is that
the condition of the if is inside the scope of the block.
> The worst are the do-blocks of many hundreds of lines.
> They tend to keep growing, and prove hard to get rid of.
Um, just turn 'em into subs. (Of course, a sub of hundreds of lines
isn't much better, but then you can start breaking it up into sensible
pieces.)
Ben
------------------------------
Date: Sun, 14 Jul 2013 17:02:44 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: [OT] scoping
Message-Id: <51e2bd94$0$15886$e4fe514c@news2.news.xs4all.nl>
On 14/07/2013 14:13, Ben Morrow wrote:
> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>> On 14/07/2013 04:24, Ben Morrow wrote:
>>> However, it's very rare to see anyone use do {} for
>>> scoping
>>
>> Often used in "libary" code here, like:
>>
>> my $sql_stmt = do {
>
> I was unclear. What I meant was, if you just want a simple variable-
> scope-limiting block, the cheapest way to do that is with a do block (in
> void context).
>
> Using do to turn a block into an expression is what it was meant for, of
> course.
Not much need for do() in void context.
>> local $" = q{,};
>>
>> qq{
>> SELECT
>> $columns_csv
>> FROM
>> $table
>> WHERE
>> id IN (@ids) -- hundreds easily
>
> Please, someone tell your cow-orkers about placeholders...
I had put the 'library' and the 'hundreds easily' there to prevent this
remark.
This kind of code is only feasible if you know the quality and security
of the parameters. The contents of @ids is, of course, strictly controlled.
With hundreds (or thousands) of placeholders, quite some CPU-time gets
wasted. That time is simply too expensive for us.
(And without type-ing, the values even get quoted.)
[...]
>> The worst are the do-blocks of many hundreds of lines.
>> They tend to keep growing, and prove hard to get rid of.
>
> Um, just turn 'em into subs. (Of course, a sub of hundreds of lines
> isn't much better, but then you can start breaking it up into sensible
> pieces.)
If we would have the time to spend on them, we would. Now we just
complain about them. They hardly ever get smaller, unless they really
annoy the dev that is hunting for the bug.
--
Ruud
------------------------------
Date: Sun, 14 Jul 2013 15:11:35 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: [OT] scoping
Message-Id: <kruf37$3vl$1@reader2.panix.com>
In article <i7haba-e8u.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>> qq{
>> SELECT
>> $columns_csv
>> FROM
>> $table
>> WHERE
>> id IN (@ids) -- hundreds easily
>
>Please, someone tell your cow-orkers about placeholders...
The classic "Bobby Tables" strip:
http://xkcd.com/327/
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 14 Jul 2013 17:34:50 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: [OT] scoping
Message-Id: <51e2c51a$0$15981$e4fe514c@news2.news.xs4all.nl>
On 14/07/2013 17:11, Tim McDaniel wrote:
> In article <i7haba-e8u.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
>> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>>> qq{
>>> SELECT
>>> $columns_csv
>>> FROM
>>> $table
>>> WHERE
>>> id IN (@ids) -- hundreds easily
>>
>> Please, someone tell your cow-orkers about placeholders...
>
> The classic "Bobby Tables" strip:
> http://xkcd.com/327/
Yeah, also doesn't apply.
See how I left out what @ids is. Now, in stead of assuming anything else
again, assume that @ids can only contain numbers, and that each is
between 1 and some maximum.
--
Ruud
------------------------------
Date: Sun, 14 Jul 2013 22:21:09 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <5bhbba-lm01.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> On 14/07/2013 14:13, Ben Morrow wrote:
> > Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> >> On 14/07/2013 04:24, Ben Morrow wrote:
>
> >>> However, it's very rare to see anyone use do {} for
> >>> scoping
> >>
> >> Often used in "libary" code here, like:
> >>
> >> my $sql_stmt = do {
> >
> > I was unclear. What I meant was, if you just want a simple variable-
> > scope-limiting block, the cheapest way to do that is with a do block (in
> > void context).
> >
> > Using do to turn a block into an expression is what it was meant for, of
> > course.
>
> Not much need for do() in void context.
A statement like
do {
...
};
is equivalent to
{
...
}
except it's a little cheaper, and the loop operators don't work.
> >> local $" = q{,};
> >>
> >> qq{
> >> SELECT
> >> $columns_csv
> >> FROM
> >> $table
> >> WHERE
> >> id IN (@ids) -- hundreds easily
> >
> > Please, someone tell your cow-orkers about placeholders...
>
> I had put the 'library' and the 'hundreds easily' there to prevent this
> remark.
>
> This kind of code is only feasible if you know the quality and security
> of the parameters. The contents of @ids is, of course, strictly controlled.
>
> With hundreds (or thousands) of placeholders, quite some CPU-time gets
> wasted. That time is simply too expensive for us.
> (And without type-ing, the values even get quoted.)
Fair enough. I'm surprised that's the case, but you've obviously tested
it with your database driver. I generally use Pg, and I'm reasonably
certain (I haven't benchmarked it) that the most efficient way to write
that statement would be with a single placeholder that gets bound to an
arrayref (which is then sent to the database as a Pg array), but
presumably that isn't the case in your situation.
Ben
------------------------------
Date: Sun, 14 Jul 2013 15:34:34 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: [OT] scoping
Message-Id: <krvbsb$unr$1@dont-email.me>
On 07/14/13 05:13, Ben Morrow wrote:
>
> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>> On 14/07/2013 04:24, Ben Morrow wrote:
>>
>>> However, it's very rare to see anyone use do {} for
>>> scoping
>>
>> Often used in "libary" code here, like:
>>
>> my $sql_stmt = do {
>
> I was unclear. What I meant was, if you just want a simple variable-
> scope-limiting block, the cheapest way to do that is with a do block (in
> void context).
>
> Using do to turn a block into an expression is what it was meant for, of
> course.
>
>> local $" = q{,};
>>
>> qq{
>> SELECT
>> $columns_csv
>> FROM
>> $table
>> WHERE
>> id IN (@ids) -- hundreds easily
>
> Please, someone tell your cow-orkers about placeholders...
...which alas don't work well with IN-lists, or column names, or table
names.
>> The worst are the do-blocks of many hundreds of lines.
>> They tend to keep growing, and prove hard to get rid of.
>
> Um, just turn 'em into subs. (Of course, a sub of hundreds of lines
> isn't much better, but then you can start breaking it up into sensible
> pieces.)
I'd much rather read one sub with hundreds of lines, than 49 individual
subs each of 10 lines, each only used once, in a linear fashion from one
meta-sub.
You should create subs when they encapsulate a nicely self-contained
re-usable nugget, not because the line count achieved a certain value.
Xho
------------------------------
Date: Mon, 15 Jul 2013 02:21:53 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: [OT] scoping
Message-Id: <51e340a1$0$15883$e4fe514c@news2.news.xs4all.nl>
On 14/07/2013 23:21, Ben Morrow wrote:
> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>> On 14/07/2013 14:13, Ben Morrow wrote:
>>> Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>>>> On 14/07/2013 04:24, Ben Morrow wrote:
>>>>> However, it's very rare to see anyone use do {} for
>>>>> scoping
>>>>
>>>> Often used in "libary" code here, like:
>>>>
>>>> my $sql_stmt = do {
>>>
>>> I was unclear. What I meant was, if you just want a simple variable-
>>> scope-limiting block, the cheapest way to do that is with a do block (in
>>> void context).
>>>
>>> Using do to turn a block into an expression is what it was meant for, of
>>> course.
>>
>> Not much need for do() in void context.
>
> A statement like
>
> do {
> ...
> };
>
> is equivalent to
>
> {
> ...
> }
>
> except it's a little cheaper, and the loop operators don't work.
Another variant: if (1) { ... }
>>>> local $" = q{,};
>>>>
>>>> qq{
>>>> SELECT
>>>> $columns_csv
>>>> FROM
>>>> $table
>>>> WHERE
>>>> id IN (@ids) -- hundreds easily
>>>
>>> Please, someone tell your cow-orkers about placeholders...
>>
>> I had put the 'library' and the 'hundreds easily' there to prevent this
>> remark.
>>
>> This kind of code is only feasible if you know the quality and security
>> of the parameters. The contents of @ids is, of course, strictly controlled.
>>
>> With hundreds (or thousands) of placeholders, quite some CPU-time gets
>> wasted. That time is simply too expensive for us.
>> (And without type-ing, the values even get quoted.)
>
> Fair enough. I'm surprised that's the case, but you've obviously tested
> it with your database driver. I generally use Pg, and I'm reasonably
> certain (I haven't benchmarked it) that the most efficient way to write
> that statement would be with a single placeholder that gets bound to an
> arrayref (which is then sent to the database as a Pg array), but
> presumably that isn't the case in your situation.
Good to mention the driver difference. Some drivers handle the 'prepare'
in Perl (at least by default), and only send the final SQL to the db-server.
Ah, the luxury of a single placeholder bound to an arrayref, and a
server side prepare. :).
--
Ruud
------------------------------
Date: Sun, 14 Jul 2013 17:04:45 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: [OT] scoping
Message-Id: <krvhlj$kgp$4@dont-email.me>
On 07/14/13 14:21, Ben Morrow wrote:
>
>
> Fair enough. I'm surprised that's the case, but you've obviously tested
> it with your database driver. I generally use Pg, and I'm reasonably
> certain (I haven't benchmarked it) that the most efficient way to write
> that statement would be with a single placeholder that gets bound to an
> arrayref (which is then sent to the database as a Pg array), but
> presumably that isn't the case in your situation.
Oooh, cool. I'll have to try that. This seems to the defy the docs of
DBI itself, so I'd never considered the possibility.
Any neat tips for making this annoying mess less of an annoying mess?
'UPDATE foo set (bar, baz, bxw, snaz1, snaz2, snaz3, snaz4,snaz5) =
($2,$3,$4,$5,$6,$7,$8,$7+$8) where pkey=$1'
Xho
------------------------------
Date: Sun, 14 Jul 2013 23:48:30 -0500
From: John Black <jblack@nospam.com>
Subject: Re: [OT] scoping
Message-Id: <MPG.2c4d3b1dfe1f6d8a989785@news.eternal-september.org>
In article <gne9ba-k9p.ln1@anubis.morrow.me.uk>, ben@morrow.me.uk says...
>
> Quoth John Black <jblack@nospam.com>:
> > In article <kk76ba-bv9.ln1@anubis.morrow.me.uk>, ben@morrow.me.uk says...
> > >
> > > Rainer has a point, buried somewhere in the bluster, in that if a sub
> > > needs to be divided into two or more bare blocks in order to limit the
> > > scope of variables those blocks should probably be diked out into
> > > separate subs. I very rarely use bare blocks, and when I do it's usually
> > > for their loop properties (so that next/last/redo will work) rather than
> > > their scoping.
> >
> > Ben, what is the meaning of a bare block? Trying to follow...
>
> A block like this:
>
> {
> my $x = ...;
> }
>
> with no other control structure attached. They can be used to limit the
> scope of a variable to something smaller than a sub; in Perl they are
> also one-iteration loops, meaning that the loop control operators (next,
> last, redo) and the loop-naming syntax will work on them.
>
> [Strictly speaking the 'barest' form of block in Perl is the do {}
> block, which, like the block form of 'if', is just a scope without any
> loop semantics. However, it's very rare to see anyone use do {} for
> scoping, partly because it looks weird and partly because do is an
> expression and so requires a trailing semicolon, like eval {}.]
Thanks!
John Black
------------------------------
Date: Mon, 15 Jul 2013 14:09:19 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: the fastest way to create a directory
Message-Id: <ks0l7j$9j4$1@news.ntua.gr>
Create a directory with all upper directories if missing.
it uses the minimum possible disk access and checks.
Mkdir_recursive('/some/dir/d1/d2') or die;
sub Mkdir_recursive
{
return 1 if $_[0] eq '' || -d $_[0];
Mkdir_recursive( $_[0] =~/^(.*?)[\\\/][^\\\/]+$/ ) || return undef;
mkdir $_[0] || return undef
}
------------------------------
Date: Mon, 15 Jul 2013 13:41:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87ip0cgfli.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Charles DeRykus <derykus@gmail.com> writes:
>>
>> > But it (illogically) stays alive longer than is needed unless you
>> > insert an additional, artificial scope as another poster showed:
>>
>> The 'logically' was supposed to refer to the fact that perl employs
>> self-defense mechanisms against code of this type by NOT doing what
>> the author requested: It keeps the variable alive despite this seems
>> 'ill/im' (arbitrary suffix attached) to some people:
>
> It explicitly does not keep the variable alive: it sets the PADSTALE
> bit, which indicates that this variable is 'dead', and prevents string
> evals and such from picking the variable up by mistake. It doesn't
> deallocate the storage used for the variable, but that's just the same
> level of optimisation as malloc uses when it doesn't reduce the brk just
> because something has been freed.
It's not: Malloc usually retains whatever 'memory' (adress space, actually) it
already requested from the kernel in order to satisfy future
allocation requests. This means that code like this
-------------------
use Devel::Peek;
sub yow
{
for (0 .. 100) {
{
my $a = "$_ + 1";
print(\$a, "\n");
Dump($a);
}
{
my $b = "$_ + 1";
print(\$b, "\n");
Dump($b);
}
}
}
&yow;
-------------------
would reuse the same space both for the $a and $b 'control blocks' and
their string bodies and that all meta-information associated with any
of these four 'logical' memory areas would be lost after each
block: There wouldn't be a way to 'set the PADSTALE bit' for any of
the scalars because whatever memory happened to be allocated to them
would turn into a completely generic 'free memory area' of a certain
size. That's not happening in this case (for perl 5.10.1 at least).
[...]
>> The computer has been programmed to work around this obsession with
>> the 'micro-optimized lifecycle management' (And this is a
>> euphemism. I'd wager a bet this this is practically just 'create a
>> new variable whenever you need one because remembering what
>> variables were created two lines ago would be SO cumbersome' [and
>> 'plan in advance variables will be needed' an imposition beyond any
>> physically tolerable by man]).
>
> We are not writing assembler, where you have a limited number of
> registers and their use needs to be planned carefully.
Programming means 'construction of algorithms', these algorithms are
usually stateful, that is, they employ variables to keep track of
'past events' and constructing such an algorithm requires a certain
amount of planning/ forethought, especially if it is supposed to be a
sensibly implemented algorithm, that is, one which both solves a
certain problem efficiently and does so without unneeded complications
putting a burden on the mind of someone trying to understand the code.
You're free to believe that you're - thankfully - absolved form the
burden of thinking about what you're going to write before you write
it because "you are not writing assembler" but so far, I haven't
encountered a more ludicrous statement about 'software development'
(and I'm fairly certain that you didn't mean to express that).
> A variable is just a way of giving a value a name;
This is true for so-called 'functional programming languages' but Perl
isn't one: There, a 'variable' is something like a deposit box
(term?): A container which can be used to store 'stuff' of a certain
kind (depending on the type of box) until it is again needed which can
be 'addressed' in a convenient way (usually, by using an abstract name
referring to the 'function' of this variable).
[...]
> The whole point of lexical variables is to avoid the problems that
> occur when uncontrolled and implicit data leakage occurs between
> different parts of the program; having Perl ensure that values we no
> longer need are properly disposed of as soon as possible is just
> common sense.
>
> (And, again, this is not about efficiency, either of CPU or memory. It's
> about making the code comprehensible.)
IMO, it is about making the code incomprehensible for the sake of
'efficiency', namely, to avoid the dreaded, mythological function call
overhead, by cramming as many different algorithms into a single run
of sequential code as seems remotely feasible instead of giving
'different things different names' and invoke them using these in
higher-level control routines. If 'possible information leakage'
becomes a problem, the constituent parts of 'the code' are way too
large and do way too many different things.
>> Do you think it was programmed to work around that because this is
>> such a great idea? I don't. Especially since the computer can only
>> work around the execution time penalty of this convention and not
>> against the mess in the source code ("which of the 1,375 $i I
>> encountered in the last 2000 lines of code is it this time?").
>
> Um, it's the one in the 'my' statement just above your cursor. That's
> the whole point of tight scoping: except for the various kinds of
> globals, which should not be created lightly and do require planning,
> the scope of a single variable should not exceed one screenful of
> code.
Except if 'screenful' is supposed to refer to 80x25, it should
usually be less: Some random 'screenful of code' I just looked at (148
lines of text) contained five different complete subroutines whose
bodies where (from top to bottome), 5 lines of text, 12 lines of text,
17 lines of text, 4 lines of text and 1 line of text.
[...]
> If you are having to deal with code which has multiple variables with
> the same name in nested scopes, some extending over hundreds of lines of
> code, you have my sympathies. That is not a code style I am
> advocating.
It's rather "multiple variables of the same type with the names spelled
somewhat differently, eg mdmCommand, MdmCommand and MDMCommand, all
supposed to contain the same thing, namely, the current MDM command,
which occur (or in this case, occurred) in the same 'hundreds of lines
of code' subroutine (Java method), with the number of different
spellings presumably equal to the number of different people who added
code to this particular method" (this is slight 'abstraction' of the
actual situation, but IMO an honest one). And without the possiblity
to 'declare variables on the spot' whenever one is needed, something
like this couldn't occur.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3990
***************************************
