Front page | perl.perl5.porters |
Postings from July 2011
Re: [PATCH] [DOCS] Modernize perlopentut.pod
Thread Previous
|
Thread Next
From:
Matt S Trout
Date:
July 17, 2011 02:40
Subject:
Re: [PATCH] [DOCS] Modernize perlopentut.pod
Message ID:
20110717093948.GR12933@agaton.scsys.co.uk
> There is abosutely nothing whatsobloodyever wrong with using
> two-argument opens on constant strings.
>
> open(FH, "> /tmp/foo.$$")
> || die "can't creat /tmp/foo.$$";
>
> is utterly fine.
Except that 'FH' can't be protected by strict, whereas
open my $fh, ...
can be.
Oh, and I'd be totally happy with two arg being introduced.
But *later*. Because in my experience most newbies read just
far enough to get *an* open to work, and then just keep on
using the first one they saw.
In fact, the only exploit of a piece of code I wrote that I
know of was because *I* stopped reading too soon and ended
up with an unsafe 2 arg open.
We recommend everybody does 'use strict' by default because
it helps protect us from ourselves. The same applies to 3
arg open, especially in a tutorial document aimed at newbies
who don't yet know enough to know when they're about to
shoot themselves in the face.
> * it repeats a filename, which is evil.
> * it doesn't include the encloding
> * it doesn't use File::Temp
And the fact you propose File::Temp - i.e. doing it the
*right* way - rather reinforces the principle.
> Furthermore, your replacements are gratuitously
> difficult to read. This serves absolutely no
> purpose but to confuse people.
In my experience, the odd scoping of bareword filehandles
compared to everythingthefuckelse confuses newbies all
the time.
I'd invite you to join me on freenode #perl for a while,
or to hang out on beginners@perl.org, or whatever. For
the kids these days, they're scary. Really. Trust me.
However, if you have specific readability complaints,
I'd love to hear them. The object here is to produce
something that causes *less* confusion, and less bullets
embedded unexpectedly in feet, and less code that makes
the next person to maintain it have to stop to get a
cloth because the blood streaming from their eyes is
about to destroy their keyboard.
But for that we need specifics rather than just an
unqualified "gratuitously difficult". I hear you're
famous for being verbose - please go for it, I'd
rather wade through an email ten times the length
of this one than write another line complaining about
lack of specificity.
> You see to think implicit closing a feature. It's
> not. It's a bug. You miss the error status, because
> not even autodie fixed the DESTROY correctly.
Closing a filehandle in a timely fashion while missing the
error status is still an improvement over leaking it until
the end of the process' runtime and still missing the error
status.
> A close is always always required. Damn it.
Ok. But instead of simply making the assertion, could you
talk about some of the things that could go wrong? I find
it hard to convince people of this because I've never, ever
actually seen the 'or die' on one of my close() statements
fire, so I don't have much ammunition for arguing it.
Such ammunition would probably form a useful part of
perlopentut.
> These changes overstate some others matters, hide
> others, and neglect still more. It is not reasonable.
Could you elaborate on that, please? A short list of
which things you consider in each category would make a
fine starting point, and then we can argue each one in
detail at a later point based on a new revision of the
patch (or patch series as I think it's inevitably destined
to become).
> In the meantime, I reject this PC crap. I would prefer
> that my documentation be wholly removed from the distribution
> than that it should be bastardized in a way that compromises
> its message and run counters to my wishes.
Tough. The Artistic License allows us to preserve and build
upon your work whether you like it or not. If you didn't
want us to do that, you shouldn't have made it that good
in the first place.
But given how good it was in the first place, I'd really
really much rather have your co-operation - but I can't
try and achieve that if you won't explain what you think
is wrong with people's suggestions.
"No, fuck off" is all very well. I hear it works really
well for Marc Lehmann. But "no, because" would be much
cooler and would give us a cat in hell's chance of
getting to yes, which would be really nice.
> I'm really tired of this damned battle. And I'm a lot
> more stubborn than you are.
Hi. I'm mst. Pleased to meet you.
> I'll start writing out funeral invitiations.
If you must. But could you send me a reply to some of
these points first so I can go poke Mike into writing
a better patch, please?
After all, if you do end up dead, somebody's got to be
able to maintain the thing, and it'd be nice to do it
in such a way that we don't provide power for the entire
eastern seabord by wire wrapping your corpse as it spins
in its grave ...
--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue
http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/
Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst
commercial support, training and consultancy packages could help your team.
Thread Previous
|
Thread Next