[31463] in Perl-Users-Digest
Perl-Users Digest, Issue: 2715 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 11 00:09:43 2009
Date: Thu, 10 Dec 2009 21:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 10 Dec 2009 Volume: 11 Number: 2715
Today's topics:
Re: foreach - sorted array the way I want? <kst-u@mib.org>
Re: foreach - sorted array the way I want? <jurgenex@hotmail.com>
Re: How big do your programs get before you modularise <cartercc@gmail.com>
Re: How big do your programs get before you modularise <ben@morrow.me.uk>
Re: How big do your programs get before you modularise <jurgenex@hotmail.com>
Re: How big do your programs get before you modularise <cartercc@gmail.com>
Re: How big do your programs get before you modularise <jurgenex@hotmail.com>
Re: How big do your programs get before you modularise <cartercc@gmail.com>
Re: How big do your programs get before you modularise <xhoster@gmail.com>
Re: How big do your programs get before you modularise <jurgenex@hotmail.com>
Re: i18n - and 2-headed strings? <nospam-abuse@ilyaz.org>
Re: i18n - and 2-headed strings? <ben@morrow.me.uk>
Re: i18n - and 2-headed strings? <nospam-abuse@ilyaz.org>
Re: Trying to avoid passing params to subs through glob <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 10 Dec 2009 16:35:00 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: foreach - sorted array the way I want?
Message-Id: <lny6lamjpn.fsf@nuthaus.mib.org>
Tomasz Chmielewski <mangoo@nospam.wpkg.org> writes:
> I have a script which reads the config file and builds the commands
> which need to be executed.
>
> It pushes each command to an array.
>
> When everything is read from the config file, it is executed like this:
>
>
> foreach my $exec_command (@exec_commands) {
> execute($exec_command);
> }
>
>
> However, such approach does not guarantee that the commands will be
> executed in a proper order.
>
>
> Supposing I would like to have the guarantee that the commands
> containing "someword" will be executed before commands containing
> "someotherword" (and this, before "xyz" command), what would be the
> best approach here?
>
>
> 1) build a hash, not an array in the first place? I'm afraid it would
> complicate it too much.
>
>
> 2)
>
>
> foreach my $exec_command (@exec_commands) {
> if ($exec_command=~m { .... }) {
> push(@execute_first, $exec_command);
> }
>
> if ($exec_command=~m { .... }) {
> push(@execute_second, $exec_command);
> }
>
> }
>
> And then, simply execute commands from @execute_first,
> @execute_second, and so on?
>
>
> 3) something else?
You might consider sorting the @exec_commands array, using a carefully
constructed comparison function.
Note that sorting is O(n*log n), whereas your approach 2 is O(n); if
the @exec_commands isn't too long this won't be too much of an issue.
You should also think about whether you have or need stable sorting
(i.e, sorting that preserves the original ordering for elements that
compare equal). "perldoc -f sort" and "perldoc sort" for more
information.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Thu, 10 Dec 2009 17:31:20 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: foreach - sorted array the way I want?
Message-Id: <o283i51f2grj4l28aumo34hmil8b7v92ce@4ax.com>
Tomasz Chmielewski <mangoo@nospam.wpkg.org> wrote:
[...]
>foreach my $exec_command (@exec_commands) {
> execute($exec_command);
>}
>However, such approach does not guarantee that the commands will be
>executed in a proper order.
Well, they will be executed in the exact sequence in which they are
stored in @exec_commands. If that is not the desired sequence, then ...
>Supposing I would like to have the guarantee that the commands
>containing "someword" will be executed before commands containing
>"someotherword" (and this, before "xyz" command), what would be the best
>approach here?
... why don't you simple sort() the commands into the proper sequence?
jue
------------------------------
Date: Thu, 10 Dec 2009 15:10:16 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <da453fd0-4e51-4fb1-b401-f1e360f5127d@j24g2000yqa.googlegroups.com>
On Dec 10, 5:33=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> I don't know what you mean by 'Perl 6 has an interactive development
> environment'.
http://perl6advent.wordpress.com/
Day 1,
CC.
------------------------------
Date: Fri, 11 Dec 2009 00:11:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <uaf8v6-t052.ln1@osiris.mauzo.dyndns.org>
Quoth ccc31807 <cartercc@gmail.com>:
> On Dec 10, 5:33 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > I don't know what you mean by 'Perl 6 has an interactive development
> > environment'.
>
> http://perl6advent.wordpress.com/
>
> Day 1,
Right. That's a REPL. How do you do any meaningful development using
that? Once you've typed in a function there's no way to get it out of
the interpreter and into a file.
Ben
------------------------------
Date: Thu, 10 Dec 2009 17:26:55 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <5q63i5lvkjpu627i14q667fuoatsjo69e9@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>On Dec 10, 8:02 am, Justin C <justin.0...@purestblue.com> wrote:
>> I keep writing programs that (for me at least) start getting large. I
>> know they're small, even by the standard of many of the modules that
>> I've seen, but how do you decide when to break down your code and
>> modularise?
>>
>> Do you only create modules if you think the code is likely to re
>> re-used, and if it's not then if the program has 10k lines then so
>> be it?
>>
>> I fine myself bashing away at the keyboard, and the next thing I know is
>> that I've got 1000 lines and keeping track of what's where starts
>> getting complicated (I do love an editor that can fold!). I was just
>> wondering how others program.
>
>From my experience, this is an incremental process.
I strongly disagree.
>First, you write a small script sequentially. It consists mostly of a
>series of statements with maybe a couple of blocks.
>
>After a while as your script grows, you see certain patterns and
>repetitions, so you move the similar statements to user defined
>functions. Then, your program consists mostly of a series of calls to
>user defined functions.
>
>Later on, the number of user defined functions increases so you decide
>to place functions with similar functionalities in files, which become
>modules. Then, your program 'uses' your modules but still consists of
>calls to functions.
That is a very poor way to write code and shows a major lack of proper
upfront design. Very often programs that have grown like that are
impossible to modularize because of random dependencies between
otherwise unrelated program parts. And for the same reason they are
extremely hard to maintain.
>The largest monolithic program I've written probably contains several
>hundred LOC. By the time you hit KLOCs, you have invariably moved to a
>modular program. It's actually pretty easy to move from sequential
>scripts to user defined functions to user defined modules - mostly a
>matter of cut and paste.
Absolutely not! Yes, there are always reasons and excuses why
refactoring code may become necessary. But refactoring is expensive in
time and cost, not to mention error prone. And recommending it as a
standard way for program development is, well, shall we just say quite a
stretch.
When you got a task, maybe just sit down and think about it for a few
hours. There is nothing gained by starting to run without knowing in
which direction to run.
Example: If I have to implement a customer management tool, then
immediately I know I will need a data type customer with at least the
usual functions like create, modify, ....
And because there will be quite a few customers I will need some sort of
customer store, a collection of customers, again with at least the usual
functions like create store, add customer, remove customer, probably
something like subset of customers filtered by some condition, ...
Furthermore I know from the requirements that search on similarities is
important. So I will want to implement something to
classify/find/evaluate/judge similarities. And obviously this has to be
done on the level of strings as well as on the level of customers.
And thus before even writing the very first line of code I already
identified 4 modules that I will need. Maybe after evaluation I will
decide to merge customer and customer store into a single physical
module, but those are minor tweaks which don't change anything about the
big picture.
You don't create modules to reduce the size of your code, you do create
modules to encapsulate and manage layers of abstraction.
jue
------------------------------
Date: Thu, 10 Dec 2009 19:04:21 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <8f10a56c-982f-4b2f-ba72-7fd8de97c41b@s31g2000yqs.googlegroups.com>
On Dec 10, 7:11=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Right. That's a REPL. How do you do any meaningful development using
> that? Once you've typed in a function there's no way to get it out of
> the interpreter and into a file.
This may or may not make sense with Perl, but it makes perfect sense
with Lisp, Erlang, and similar languages. You commonly pass functions
as arguments to other functions, and return functions from functions,
and it's critical to ensure that the functions you pass as arguments
or return behave as they ought. Much of this can be trial and error,
or a process of optimization.
I'm not proficient in Lisp by any stretch, but I currently write Lisp
on a daily basis. When writing a function, I don't start in the
editor, but on the REPL. I play with it until I get it the way that I
want, then (in emacs) copy the sexp, switch the the file buffer, and
yank it.
For example, in chapter 3 of Practical Common Lisp, we have this
example:
(defun prompt-for-cd ()
(make-cd
(prompt-read "Title")
(prompt-read "Artist")
(or (parse-integer (prompt-read "Rating") :junk-allowed t) 0)
(y-or-n-p "Ripped [y/n]: ")))
The function prompt-for-cd contains four other functions, make-cd,
prompt-read, parse-integer, and y-or-n-p. prompt-read is defined as
defun prompt-read (prompt)
(format *query-io* "~a: " prompt)
(force-output *query-io*)
(read-line *query-io*))
The REPL allows you to play with the functions until you get them
right. If you could imagine developing a Perl program in an
environment that allows you to write and test individual user defined
functions BEFORE INCLUDING THEM IN THE PROGRAM you would be close to
the idea. Also, this encourages your functions to be self-contained,
so you avoid many of the errors that can develop from dependencies
between functions.
I'm not advocating one language or style of development. There are
reasons that Perl is a lot more popular than Common Lisp, and Java a
lot more popular that Perl. I'm just saying, based on my personal
experience, that developing a program piece by piece, function by
function, by interactively testing them in the REPL, is efficient and
productive in certain ways.
CC.
------------------------------
Date: Thu, 10 Dec 2009 19:14:35 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <nqd3i5t5q34q8fcqrqvjar1hairctsig2l@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>On Dec 10, 7:11 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> Right. That's a REPL. How do you do any meaningful development using
>> that? Once you've typed in a function there's no way to get it out of
>> the interpreter and into a file.
>
>This may or may not make sense with Perl, but it makes perfect sense
>with Lisp, Erlang, and similar languages. You commonly pass functions
>as arguments to other functions, and return functions from functions,
Sure, those are just HOF, aka higher order functions aka functions as
first-class citizen. Nothing special about them.
>and it's critical to ensure that the functions you pass as arguments
>or return behave as they ought. Much of this can be trial and error,
>or a process of optimization.
Aeeeehmmmm, no. There is nothing special about a function that is passed
as an argument, and you can design and develop and write them just like
any other function in your program. Perl supports HOFs in a somewhat
simplified form, e.g. as the first parameter of sort(my_cmp ($a, $b),
@somearray) or File::Find::find(\&wanted).
And there is absolutely nothing special about writing or testing
my_cmp() or wanted() and you certainly don't need any special tools to
do so.
jue
------------------------------
Date: Thu, 10 Dec 2009 19:33:37 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <d9ec03d4-4968-47ba-8593-15c2929f96ca@m16g2000yqc.googlegroups.com>
On Dec 10, 8:26=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> >From my experience, this is an incremental process.
>
> I strongly disagree.
I'm a database guy, and my main responsibilities is to munge data,
typically by running database queries and then processing the data. My
typical 'program' is between 50 and 100 lines. Most of the time, these
scripts are throw-aways. Occasionally, I'll develop a script that
grows and grows, but I usually can't tell in advance which is which.
> >Later on, the number of user defined functions increases so you decide
> >to place functions with similar functionalities in files, which become
> >modules. Then, your program 'uses' your modules but still consists of
> >calls to functions.
>
> That is a very poor way to write code and shows a major lack of proper
> upfront design. Very often programs that have grown like that are
> impossible to modularize because of random dependencies between
> otherwise unrelated program parts. And for the same reason they are
> extremely hard to maintain.
There really isn't a call for upfront design when you write a script
that inputs a CSV file 12 columns across, sort it by three fields, and
output a PDF file with the sorted data. It's as easy to write through
it as to think through it, and a lot quicker.
> >The largest monolithic program I've written probably contains several
> >hundred LOC. By the time you hit KLOCs, you have invariably moved to a
> >modular program. It's actually pretty easy to move from sequential
> >scripts to user defined functions to user defined modules - mostly a
> >matter of cut and paste.
>
> Absolutely not! Yes, there are always reasons and excuses why
> refactoring code may become necessary. But refactoring is expensive in
> time and cost, not to mention error prone. And recommending it as a
> standard way for program development is, well, shall we just say quite a
> stretch.
I didn't way that I refactored the code. What I said was 'copy and
paste' - by which I mean that I slap a sub <name> { ... } block around
the code and move it out of the sequence. By far most of my code is
for my own use, and while I will refactor code that I use over a
period of time, this isn't very common for me.
> When you got a task, maybe just sit down and think about it for a few
> hours. There is nothing gained by starting to run without knowing in
> which direction to run.
When I get a task, my user expects the results quickly, and I'm
generally successfully completing the task in less than an hour. By
the time I write the database query, I have already thought through
the entire process -- you really have to in order to have the data in
a form most conductive for creating the output.
> Example: If I have to implement a customer management tool, then
> immediately I know I will need a data type customer with at least the
> usual functions like create, modify, ....
> And because there will be quite a few customers I will need some sort of
> customer store, a collection of customers, again with at least the usual
> functions like create store, add customer, remove customer, probably
> something like subset of customers filtered by some condition, ...
> Furthermore I know from the requirements that search on similarities is
> important. So I will want to implement something to
> classify/find/evaluate/judge similarities. And obviously this has to be
> done on the level of strings as well as on the level of customers.
>
> And thus before even writing the very first line of code I already
> identified 4 modules that I will need. Maybe after evaluation I will
> decide to merge customer and customer store into a single physical
> module, but those are minor tweaks which don't change anything about the
> big picture.
Example: give me a report of active students who have completed 30
hours without taking the required MATH and ENG classes or have not
completed their placement tests, and sort them by program and adviser.
Zero modules, and probably zero functions -- just one block of
monolithic code, probably about 50 lines, which would take maybe 15
minutes to write, and I'll most likely not use it again.
Perhaps twice a year I'll get an assignment like your example, and
typically I'll use Java for it, so yes, I ABSOLUTELY AGREE (!) that
thought and planning is necessary for a more complex project. However,
for me, Perl development is an incremental process that mostly doesn't
increment.
CC.
------------------------------
Date: Thu, 10 Dec 2009 19:55:30 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <4b21cbf5$0$7850$ed362ca5@nr5-q3a.newsreader.com>
Sir Robert Burbridge wrote:
>
> That makes packaging it pretty trivial when it grows past that.
> Sometimes putting a couple minutes of thought into it first shows me
> that it should *start out* modularized.
I actually find this rather rare. If I can come up with a modular
design within a couple minutes, then almost certainly those modules have
already been thought of and already exist on CPAN, and I should use
those rather than writing my own. When a module doesn't already exist,
I've found that dashing out to write one based on a few minutes of
hubris and navel gazing is not the most propitious start.
Xho
------------------------------
Date: Thu, 10 Dec 2009 20:52:37 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: How big do your programs get before you modularise most of it?
Message-Id: <3mj3i5duenicqs0st0dpb560r418chhi1g@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>Example: give me a report of active students who have completed 30
>hours without taking the required MATH and ENG classes or have not
>completed their placement tests, and sort them by program and adviser.
You don't need a program for that! That's just one SQL statement (which
may take a few minutes to think about) and then an output to PDF if that
is required. The only stumbling block might be to find a converter, that
converts the SQL response into PFD. Otherwise it's at most a one-liner
in any shell, no need for Perl.
If you find yourself doing those queries often it would probably pay of
to create a generic tool (with a nice GUI for the not-so-gifted) such
that your users can easily create their own reports.
jue
------------------------------
Date: Thu, 10 Dec 2009 23:15:24 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: i18n - and 2-headed strings?
Message-Id: <slrnhi308c.8gf.nospam-abuse@powdermilk.math.berkeley.edu>
On 2009-12-10, Ben Morrow <ben@morrow.me.uk> wrote:
>> Thinking about it more:
>> A) I find the argument that Perl is a "lingua franca of science and
>> technology" very misplaced. *A Perl application* may be designed
>> for use by children and/or music lovers.
> Um, yes? Who are you arguing with? :)
Whoever wrote this (earlier in the thread).
>> B) We need something which works as English during parsing, but is
>> printed out in Bengali. This looks like overloading.
>>
>> Unfortunately, when I designed overloading, I did not think *at
>> all* about overloading objects with string semantic. There was
>> no provision to treat REx matching specially during overloading,
>
> There is now. I submitted a patch to add 'qr' overloading to 5.12, which
> is called when an overloaded object is used on the RHS of =~ or is
> interpolated into a regex. Since 5.12 has true REGEX SVs, it seemed
> silly not to have a corresponding 'type-cast' overload.
Good. But what I was "hinting at" was the LHS of "=~" ...; which is a
string. And "a string" != "a REx" (after appropriate overloading of != ;-)
>> Basically, what I think of is making $@ into a 2-headed beast, with 2
>> different STRING values. What do people think?
> There was some discussion of this issue on p5p a while ago, though that
> was before qr-overload was different from string-overload. IIRC the
> general feeling was that trying to get people to move away from
> string-matching $@ by defining a set of numeric error codes for the core
> perl errors was probably the best way forward.
I would hate numeric errors.
(When my system boots, there is a chance
of getting an error message which essentially says:
!!! SYS2025
!!! SYS2027
Very enjoyable. (Explanation: the system knows many different ways to
expand these to much more human-readable form. But
the system did not even start booting yet, so has no
idea in which language to bash you...))
I would very much prefer "short descriptive english strings" approach.
ERROR_DISK_READ, ERROR_DISK_NONBOOT would have similar (un)convenience
for paper manual lookup, and would have some chance for the meaning to
be guessed without the manual. [*]
Anyway, this is a pipe dream. The code DOES do $@ =~ /foo/.
Ilya
[*] P.S. On the other hand, one of my friends worked as
"non-customer support" in a certain establishment of
more or less technical nature. Non-customers were kinda
engineers. So a call about the error above might sound like:
The 1st and 3rd symbols look like snakes; the second forks;
then comes number 2025. What to do?
(I did not believe this at first, but this did not sound
like a joke.) In such situation, reducing number of
distinct non-digits to two DOES help...
------------------------------
Date: Fri, 11 Dec 2009 00:07:04 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: i18n - and 2-headed strings?
Message-Id: <82f8v6-t052.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2009-12-10, Ben Morrow <ben@morrow.me.uk> wrote:
>
> >> B) We need something which works as English during parsing, but is
> >> printed out in Bengali. This looks like overloading.
> >>
> >> Unfortunately, when I designed overloading, I did not think *at
> >> all* about overloading objects with string semantic. There was
> >> no provision to treat REx matching specially during overloading,
> >
> > There is now. I submitted a patch to add 'qr' overloading to 5.12, which
> > is called when an overloaded object is used on the RHS of =~ or is
> > interpolated into a regex. Since 5.12 has true REGEX SVs, it seemed
> > silly not to have a corresponding 'type-cast' overload.
>
> Good. But what I was "hinting at" was the LHS of "=~" ...; which is a
> string. And "a string" != "a REx" (after appropriate overloading of != ;-)
Of course you were. Sorry.
I think the most immediate response from p5p would be 'that's what the
new ~~ operator is for, which is already overloadable', and in general I
would agree that having two 'stringifications' was seriously confusing.
However, since this is (just) for back-compat hacks, it's possible a
case could be made. Maybe I should just do up a patch...
> >> Basically, what I think of is making $@ into a 2-headed beast, with 2
> >> different STRING values. What do people think?
>
> > There was some discussion of this issue on p5p a while ago, though that
> > was before qr-overload was different from string-overload. IIRC the
> > general feeling was that trying to get people to move away from
> > string-matching $@ by defining a set of numeric error codes for the core
> > perl errors was probably the best way forward.
>
> I would hate numeric errors.
>
> (When my system boots, there is a chance
> of getting an error message which essentially says:
>
> !!! SYS2025
> !!! SYS2027
>
> Very enjoyable. (Explanation: the system knows many different ways to
> expand these to much more human-readable form. But
> the system did not even start booting yet, so has no
> idea in which language to bash you...))
The idea was most certainly not to remove the string errors. It was more
along the lines of setting $@ to a dualvar (just like $!), though I
think everyone was assuming it would be worth making this actually an
overloaded object. Obviously the English error messages should be
compiled into the binary, so there is some fallback if whatever i18n
files are needed can't be loaded.
> I would very much prefer "short descriptive english strings" approach.
> ERROR_DISK_READ, ERROR_DISK_NONBOOT would have similar (un)convenience
> for paper manual lookup, and would have some chance for the meaning to
> be guessed without the manual. [*]
The trouble is distinguishing between 'stringify for human consumption'
and 'stringify for unambiguous matching'. Stringify and numify are
already clearly different operations, and there is precedent in the way
$! is used (anyone doing string matching on $! is insane :) ).
Ignoring back-compat, smartmatch would be a good fit here. It would be
trivial to make an object that stringifies to some localized message but
passes $@ ~~ "UNDECLARED_VARIABLE".
> Anyway, this is a pipe dream. The code DOES do $@ =~ /foo/.
That is the problem, yes.
> [*] P.S. On the other hand, one of my friends worked as
> "non-customer support" in a certain establishment of
> more or less technical nature. Non-customers were kinda
> engineers. So a call about the error above might sound like:
>
> The 1st and 3rd symbols look like snakes; the second forks;
> then comes number 2025. What to do?
>
> (I did not believe this at first, but this did not sound
> like a joke.) In such situation, reducing number of
> distinct non-digits to two DOES help...
It sounds entirely believable to me, assuming the caller spoke a
language that doesn't use the Latin alphabet but does use Arabic
numerals. For example, although Chinese has its own numerals, it seems
to be quite common to use Arabic instead.
Ben
------------------------------
Date: Fri, 11 Dec 2009 00:26:28 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: i18n - and 2-headed strings?
Message-Id: <slrnhi34dk.8li.nospam-abuse@powdermilk.math.berkeley.edu>
On 2009-12-11, Ben Morrow <ben@morrow.me.uk> wrote:
>> [*] P.S. On the other hand, one of my friends worked as
>> "non-customer support" in a certain establishment of
>> more or less technical nature. Non-customers were kinda
>> engineers. So a call about the error above might sound like:
>>
>> The 1st and 3rd symbols look like snakes; the second forks;
>> then comes number 2025. What to do?
>>
>> (I did not believe this at first, but this did not sound
>> like a joke.) In such situation, reducing number of
>> distinct non-digits to two DOES help...
>
> It sounds entirely believable to me, assuming the caller spoke a
> language that doesn't use the Latin alphabet but does use Arabic
> numerals.
Of course. What made is hard to believe is that the country in
question is (at least up to some extend) a part of "extended Europe"
nowadays (IIRC, it takes part in some European sport competitions etc).
And AFAIU the story does not make sense applied to, e.g., Russian-speakers...
Ilya
------------------------------
Date: Thu, 10 Dec 2009 23:45:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Trying to avoid passing params to subs through globals
Message-Id: <ipd8v6-tr42.ln1@osiris.mauzo.dyndns.org>
Quoth Tad McClellan <tadmc@seesig.invalid>:
> Ben Morrow <ben@morrow.me.uk> wrote:
>
> > you might have
> >
> > my %excel;
> >
> > create_worksheet(\%excel);
> > populate_worksheet(\%excel);
> >
> > sub create_worksheet {
> > my ($excel) = @_;
> > $excel{ws} = Worksheet->new;
>
>
> Oops!
>
> We are modifying %excel and not using the $excel parameter for anything...
>
> $excel->{ws} = Worksheet->new;
> ^^
> ^^ I'm pretty sure this is what Ben meant to write...
Yes. Thank you.
> > }
>
> Which leads to one of _my_ style points: don't use similar-looking names.
>
> If we had followed that style rule, and made the same mistake:
>
> my $excel; # a "long" form of the name in this big scope
>
> create_worksheet(\%excel);
> populate_worksheet(\%excel);
>
> sub create_worksheet {
> my ($xl) = @_; # a "short" form of the name in this little scope
> $xl{ws} = Worksheet->new;
> }
>
> then perl would have found the mistake for us (assuming "use strict").
I tend to use names with initial caps for file globals, where they are
necessary, for exactly this reason. It's worth pointing out at this
point that had %excel been minimally-scoped to start with 'strict' would
also have caught the error:
main();
sub main {
my %excel;
create_worksheet(\%excel);
}
sub create_worksheet {
my ($excel) = @_;
$excel{ws} = ...; # %excel is not in scope here
}
Of course, a block will do just as well as a sub, if you're certain it
will only ever be called once.
Ben
------------------------------
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 2715
***************************************
