>+ lc Lowercase a string
>+ lcfirst Lowercase first char of a string
>+ uc Uppercase a string
>+ ucfirst Uppercase first char of a string
Not quite; the last one (for ucfirst or \u) should be Titlecase,
not Uppercase--which of course, are not always the same.
Co
What the heck is this:
Section 5 of the F file is devoted to "Networking, Device Control
(modems), and Interprocess Communication", and contains numerous unbundled
modules numerous networking modules, Chat and Expect operations, CGI
programming, DCE, FTP, IPC, NNTP, Proxy,
On 09 Nov 2010 06:02:55 GMT you wrote:
>> For now, I'm sending the complete revision in toto.
> Applied as cf21866, with some tpyo corretcions.
Thanks very muhc. I think it's a better document now,
even if only marginally.
===
TYPOS
===
Even though my last step was to spell-check it,
> Personally I really wish you had kept the changes to use lexically
> scoped filehandles.
That's fine. I'm certainly not *against* lexically scoped indirect
filehandles--except for all the extra syllababbles of English it takes
to *mention* them:(--provided it doesn't complicate things or intro
Abigail wrote:
> Before 5.6, lexical scoped file handles were possible, but everyone
> used globs, and the world didn't stop turning. Collision was so
> infrequent, noone wanted to type the few extra keystrokes.
Plus the ALL_CAPPED names really stood out, further decreasing
the chance of collisi
> Ultimately it's your call, but I think the Cookbook references should
> be in there.
Thanks, Brian.
I still feel that I must recuse myself from making that call.
--tom
> I agree with you in theory, but in practice I think it doesn't matter
> most of the time: most of the time people don't check the return
> values of their print() calls, making the point of checking close() a
> bit moot IMHO.
It is neither necessary nor sufficient to check the return value
fro
>On Wed, Nov 10, 2010 at 3:58 AM, Tom Christiansen wrote:
>> It is neither necessary nor sufficient to check the return value
>> from print to detect an error in print.
>I agree it's not sufficient, but I don't agree it's not necessary.
>Just imagine a progr
I wrote, quoting Leon:
most of the time people don't check the return values of their
print() calls, making the point of checking close() a bit moot
IMHO. Also, closing a valid read-only filedescriptor can't even
generate an error AFAIK.
>>> Certainly it can!!
>> Enlighten me
; <9217.1289400...@chthon>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
X-Mailer: nmh v1.3 && nvi v1.79 (duh!)
Date: Wed, 10 Nov 2010 17:50:52 -0700
Message-ID: <32724.1289436...@chthon>
From: Tom Christiansen
> I still have a ha
>They are still important, because the people who are trying to help the Perl
>beginners, are often presented with badly written code, and having code like
>that in the core Perl documentation only amplifies the problem, and makes us
>look bad.
That is *not* badly written code.
--tom
> after I posted my series of patches to perlipc.pod , I saw that
> tchrist posted his version, which got accepted immediately. As a
> downside to that, I'll have to restart my work. However, I noticed
> that perlipc.pod still has many perceived issues.
Having real issues is quite distinct from h
>On Fri, Dec 3, 2010 at 3:56 PM, Tom Christiansen wrote:
>>> We need to make it use strict friendly.
>>
>> No, we do not. =C2=A0Vide fricking supra.
>We do, honestly. I'm tired of having to explain to newbies why the
>official perl documentation is not stri
>On Friday 03 December 2010 at 16:53, Leon Timmermans wrote:
>> We do, honestly. I'm tired of having to explain to newbies why the
>> official perl documentation is not strict friendly, when I tell them
>> they should use strict. **I don't know how to explain that to them**,
>> it simply doesn't c
I was simply showing which examples from perlfunc
are wrong by the high and mighty approach.
It is ridiculous to insist on mying them all.
That was my point.
--tom
There *are* real problems in the documenation.
But the fact that something is described as
sin($x)/cos($x)
without a my declaration, is *not* one of them.
The biggest problem is that it is too hard to find the right
information where you're looking for it, because it's scattered
all over t
>> I don't believe you.
> Are you suggesting I'm lying??
No. I'm saying that I find it unbelievable. Perhaps
you have a selective memory. Perhaps you are forgetting
things, or remembering others.
But yes, I mainly teach programmers programming.
I don't have a great deal of success with nonpr
Yves wrote:
> Well, that is not entirely correct. Some /are/ full blown programs.
*Those* I do try to always my() or our() or state() or sometimes
even local(), which is indeed appropriate in places:
use Carp qw< :DEFAULT cluck >;
if (something_or_other) {
local $SIG{__WARN__} =
>> It's the isolated snippets like the zillion I last night pointed out in
>> perlfunc where I feel all the declaration detracts from the point.
>>
>> If you believe that every possible example in Perl needs to be fully
>> declared, than by all means do so. But make sure you always start every
>>
Yes, I'm depressed too.
I'm depressed that people are telling me that I don't talk good no more.
That there is something about my language that isn't safe for the precious
children to hear. That there are things one isn't supposed to do--not that
they're illegal or anything, just that they're "ad
> The way I see it what happened was that I wrote an email with aspects of
> perlipc.pod that I found lacking, and not idiomatic up to recent best
> practices, thcrist replying that he doesn't like any of the changes and
> VETOing them (without saying why the status quo was better, just by givin
21 matches
Mail list logo
