On Jan 24, 2008 7:49 AM, Rob Dixon <[EMAIL PROTECTED]> wrote: snip > >> Of course. Thanks Chas. I think the docs could do with a tweak here. > > > > They seem fine to me: > > > > from perldoc strict > > "strict refs" > > This generates a runtime error if you use symbolic references > > snip > > "strict vars" > > This generates a compile-time error if you access a variable > > that > > wasn't declared via "our" or "use vars", localized via "my()", > > or > > wasn't fully qualified. > > snip > > "strict subs" > > This disables the poetry optimization, generating a > > compile-time > > error if you try to use a bareword identifier that's not a sub- > > routine, unless it is a simple identifier (no colons) and that > > it > > appears in curly braces or on the left hand side of the "=>" > > sym- > > bol. > > > > The effects and when they happen is fairly clearly spelled out. > > Humorously enough, > > > > use strict subs; > > > > violates itself, but it can't catch the error (since it occurred > > before $^H was set). > > And even that's an improvement IMO. In the full version the > 'compile-time error' and 'runtime error' qualifications are at the start > of a long exposition of what conditions trigger the the pragma and I > think they belong in a sentence of their own. snip
Well, you could always make a patch and send it to p5p. snip > The critical point is that the /checks/ are run time ones or compile > time ones. It was easy for me to overlook the type of error generated, > as it simply doesn't matter as long as it generates one. snip Ah, I see the issue. You are reading compile-time and run-time as types of error rather than as adjectives that tell you when the error can occur (i.e. when the checks are run). I am not sure how to fix that. Someone could just as easily skip over your sentence stating when the error could occur in their hurry to see what causes it. Not much can be done to help people who only skim documentation. This is why I always say a programmers most important skill is his or her ability (and desire) to read. snip > It's incorrect in that my code /does/ fulfil the listed conditions for > generating a > compile-time error: it accesses @data which hasn't been declared. > According to the description this should magically generate a > compile-time error but it didn't. The fact that to do so would be > impossible because a run time event can't trigger a compile time error > doesn't make the write-up correct. snip Yes, it does. It states that the error occurs at compile time. The problem is that you are accessing the variable through a runtime mechanism that should be turned off by another part of strict. You are looking at strict in pieces and it is intended to work as a whole. The reason the pieces are there is to let you relax the strictness if you know what you are doing. The important part there is knowing what you are doing. I hold that there is no good reason to turn off any part of strict when using Perl as programming language (as opposed to using it like grep or other tools on the command line). Each piece of functionality it turns into an error has a better approach available: refs: use real references for referencing and use hashes for dynamically created variable names vars: use my and our variables subs: quote your strings snip > At the very least, there's an error in that it should read '... and > wasn't fully qualified'. :) snip Hmm, that is iffy. I keep rereading the sentence and it is like the face/vase optical illusion. A copy-editor friend of mine says it is because of the break in parallelism on the second item. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
