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

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)

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...

Replies are listed 'Best First'.
Re: find and replace project with values coming from a table
by Abigail-II (Bishop) on Jul 06, 2003 at 21:23 UTC
    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

      Despite not being a native English speaker, I'm familiar with the meaning of enclosing

      Gah. If ive insulted you then I apologise unreservedly. I certainly had no intention of doing so.

      So, what kind of scope do you think it is (in relation to $")?

      Not an enclosing one. To me file level scope can not really be considered to be an enclosing scope. Sure its a scope, buts its hardly an enclosed one. To me enclosure requires a fence of some sort, as the definition says it must be "surrounded on all sides, fenced in to prevent common use". A file isnt surrounded on all sides, whereas a block is.

      To use an analogy from geography: the island Great Britian could be construed as a scope, yet it can hardly be construed as enclosed (by anything other than the sea that is), whereas my aunt and uncles property can be. In other words I see a file as being like an island, and a block like a fenced in field. (And a package like a country. The more i think about this analogy the more i like it :-) The island represents a scope but is not really enclosed, but it can contain any number of enclosures.

      Anyway, I dont mean to play word games with you, just to explain the spirit or sense in which i used the term "enclosing scope". And if you reread my original post you'll see I used the phrase "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" (italics added of course). Which I think at least shows that im not trying to wriggle off the hook here :-)

      If you follow the analogy further, and island can grow or shrink without really changing its nature (its still an island). But for an enclosure to grow or shrink somebody has to move the fence. Likewise with files and blocks. A block doesnt get bigger unless you move the braces (even if your editor does it for you :-). A file gets bigger by just adding a new line to the end. Nothing physicial (in a digital context) has to move.

      Cheers,


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
        I'd say the island and the fenced in area are very similar. Moving a fence doesn't change the nature of the fenced in area (unless you let the fence intersect with itself). As for the island growing or shrinking, well, that means you have to move the sea. Just like you have to move the fence. No difference.

        As for adding a new line to the end of the file, the end-of-file point moves - just like the closing brace "moves" if you add a line to the end of the block. The fact that in some OSses there isn't an end-of-file byte because it can be determined by another piece of information kept by the OS isn't relevant - that happens on a far lower level than Perl.

        A file is a block that follows the same scoping rules as blocks bound by braces.

        Abigail