in reply to Re: find and replace project with values coming from a table
in thread find and replace project with values coming from a table

There are a couple of minor issues with this implementation related to the last bit of code (to print out the results).

First off, it is extremely unwise to set any punctuation vars (which $LIST_SEPERATOR happens to be, even if it doesnt look it) without utilizing a local and an enclosing scope. Even though it isnt directly an issue in the code you posted its best not to get into bad habits. (This criticism applies to Abigail-II as well. You and he probably know when this is ok and when not, but it is unlikely the OP does. :-)

Second is the use of use English; which unless this has been fixed (I dont know if it has or not in newer perls, and certainly hasnt in older ones) then the module carries an unnacceptable performance penalty for programs that use regexes. (It triggers "saw-ampersand" which causes regexes to be signifigantly slower in ALL code used in the current running interpreter.) The general rule of thumb is to not use English but just learn the mnemomics of the punctuation vars. $" and $, are not difficult to remember IMO, even if they do look weird.

Anyway, all that aside IMO Its better to just say

# And show the resulting array. foreach my $row (@data) { print qq(["),join('", "',@$row),qq("]\n); }

as it actually works out that even when you use $" or $, directly that the join statement is less chars to type:

{local$"=','; print "@array\n";} print join(',',@array),"\n";

And doesnt have any potential for accidental action at a distance which is what you get by setting any of the punction vars without localizing them as tightly as possible.

Anyway, it was cool of you to produce a "beginners" version of Abigail-IIs code. ++ to you.


---
demerphq

<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

Replies are listed 'Best First'.
Re: find and replace project with values coming from a table
by Abigail-II (Bishop) on Jul 05, 2003 at 22:20 UTC
    First off, it is extremely unwise to set any punctuation vars (which $LIST_SEPERATOR happens to be, even if it doesnt look it) without utilizing a local and an enclosing scope.

    It's not possible not to have a scope in a Perl program. Remember that a file is a block as well. I'd considered using local, but then dismissed it as not necessary - the program is about to end anyway. Why have Perl save the old value of $" and restore it, if you're not going to use the old value?

    Second is the use of use English; which unless this has been fixed (I dont know if it has or not in newer perls, and certainly hasnt in older ones) then the module carries an unnacceptable performance penalty for programs that use regexes.

    use English "-no_match_vars"; is as old as at least 5.6.0, if not older. Furthermore, the program isn't using regular expressions, so the argument doesn't old anyway. There is however, IMO, a stronger argument to not use English.pm. The majority of the code, and the majority of the programmers out there don't use this module. If you use English.pm, it becomes harder for you to understand programs written by others (because you aren't used to those variables), and others find it harder to understand your programs (because others don't recognize the variables).

    Abigail

      It's not possible not to have a scope in a Perl program. Remember that a file is a block as well.

      Oh I know this well. Thanks for pointing out the potential for misunderstanding, I shouldnt have assumed that everybody (especially non native english speakers) would grasp the signifigance of "enclosing". Just so you can see the point I meant Ive included the definition of "enclosing" below. (Definitions 1-3 are relevent IMO)

        en·close   ( P )   also in·close
        tr.v. en·closed, en·clos·ing, en·clos·es
        1. To surround on all sides; close in.
        2. To fence in so as to prevent common use: enclosed the pasture.
        3. To contain, especially so as to envelop or shelter: “Every one of those darkly clustered houses encloses its own secret” (Charles Dickens).
        4. To insert into the same envelope or package: enclose a check with the order.


        [Middle English enclosen, from Old French enclos, past participle of enclore, from Latin includere, to enclose. See include.]
        Synonyms: enclose, cage, coop, fence, hem, 1pen, 2wall
        These verbs mean to surround and confine within a limited area: cattle enclosed in feedlots; was caged in the office all afternoon; was cooped up in a studio apartment; a garden fenced in by shrubbery; a battalion hemmed in by enemy troops; ships penned up in the harbor; prisoners who were walled in.
      Enslosing at Dicitionary.Com

      I'd considered using local, but then dismissed it as not necessary - the program is about to end anyway. Why have Perl save the old value of $" and restore it, if you're not going to use the old value?

      Well, first off I agree (and I did say that I knew you knew this stuff :-) that in a quick and dirty that was for one-off or personal use that I might not use local. OTOH, I tend to wrap global var changes in as tight a block as I can just because once or twice Ive forgotten that I have not done so and then had to waste time finding the damn thing after the fact. This is what I mean by bad habits. Also as this answer is aimed at a newbie, I felt that pointing out the issue might avoid trouble. After all, you and I know that if we add anything after the global var assigment that we also probably will need to block in and localize the assignment. The OP probably wouldnt know such things so I felt it was prudent to add the comment to the thread.

      use English "-no_match_vars"; is as old as at least 5.6.0, if not older.

      Hmm, thanks, I was unaware of that option. Mostly becuase I dont use it due to its earlier reputation.

      Furthermore, the program isn't using regular expressions, so the argument doesn't old anyway.

      Well, I thought that the implication of saying "the module carries an unnacceptable performance penalty for programs that use regexes." was clear that it didnt apply directly here. Again, thanks for the follow up, I should take more care with my explanations.

      There is however, IMO, a stronger argument to not use English.pm. The majority of the code, and the majority of the programmers out there don't use this module.

      Bravo! This is indeed this is a very good argument for not using English.pm.

      Cheers,


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
        Despite not being a native English speaker, I'm familiar with the meaning of enclosing - there was no need to quote dictionaries. But, while you and I agree on the meaning of enclosing, it seems you and I disagree whether $" was in an enclosing scope or not. I think a file is an enclosing scope. Which would mean, you think it isn't. You do agree it's a scope though. So, what kind of scope do you think it is (in relation to $")?

        Abigail

      THANK YOU ALL SO MUCH FOR YOUR HELP! I'll spend the weekend digesting it all. I truly appreciate your time. Sean:)