develooper Front page | perl.perl5.porters | Postings from February 2013

Re: Don't patch perlopentut: rewrite it completely

Thread Previous | Thread Next
Tom Christiansen
February 17, 2013 17:42
Re: Don't patch perlopentut: rewrite it completely
Message ID:
In-reply-to David Golden <> message 
    dated "Sun, 17 Feb 2013 06:24:48 -0500."

>On Sat, Feb 16, 2013 at 8:30 PM, Tom Christiansen <> wrote:
>> SUMMARY: Let's rename perlopentut and write a new one from scratch.

> +1

> I think a  newbie tutorial rewrite is a good idea.  Thank you for
> stepping back, realizing that, and providing a draft.

Thanks you.

> I have smallish quibbles, some factual (perlfaq5 vs perlfaq4), and
> some stylistic and a bunch of thoughts which are less well resolved in
> my head.

I didn't check the refs carefully.  Those were just WAGs.  The important
thing is to give pointers to the detailed material.

> I do appreciate the switch to showing 3-arg open.  I strongly favor
> showing "or die..." instead of "|| die..." because the lower
> precedence operator is safer should parentheses be omitted.

But they shoudln't. :)

> *Note*: I am *not* advocating removal of parentheses nor saying that
> "||" is invalid or wrong.  I'm saying that the low-precedence "or" for
> trailing statement clauses is more robust in the face of programmer
> error and is thus a better style for newbies to copy from.

> I really appreciate the strong statement about specifying encodings
> explicitly.  It may not be common in practice, but it is *exactly* one
> of those things that people were never taught and thus rarely do.

This is really important.  We need to get people into the habit of 
realizing that there is no such thing as a "textfile" any longer.
Instead there are myriad different kinds of textfiles.  

If you do not specify the encoding, you have made a mistake.

> I think pipes and sysopen can be left to a "more than you wanted to
> know" document.

That would sure be nice.

> I would mention "flock" in perlfunc as well as pointing to perlfaq5.


> I wonder if it is worth discussing IO::File->new and the equivalence
> to "open".  (At the end -- in a section about IO::File specifically,
> most likely).

At $job I have to maintain MANY HUNDREDS of scripts that were written 
before handle autoviv.  Those that need things like an array of handles
do use IO::File->new to get these.

I'm afraid that we need to put a 

    use v5.6;		# for handle autoviv
    use v5.8;		# for good I/O layers
    use v5.10;		# for // die
    use v5.14;		# for autoload of IO::Handle

which while arguably annoying, would be worse without those.

We also need to give a pointer to somewhere that has directions
for what to do if those conditions do not hold.  And no, I do 
not mean a pointer to a newer version of Perl.   I mean a pointer
to directions of how to get your job done without an upgrade.

> Likewise, I wonder if it is worth discussing autoflush or how files
> don't get flushed to close.  (I leave the question of error checking
> close to the other thread. :-)

What does "don't get flushed to close" mean?  You mean "until close"?

Buffering.  Blah.  I'm tempted to add


But then of course I have to add

    use IO::Handle;

or at least

    use if ($] < 5.014), "IO::Handle";

Ick.  The versioning thing is a real barrier.

> I wonder if it is worth briefly mentioning that binmode is not really
> the same as specifying an encoding on open, or if this just opens the
> Pandora's box of evil that is PerlIO layers.


> I think it is worth mentioning (briefly) that "write" is not the
> opposite of "read".




Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About