dcmertens.perl at gmail
May 8, 2012, 8:20 AM
Post #13 of 13
On Tue, May 8, 2012 at 5:25 AM, Nicholas Clark <nick [at] ccl4> wrote:
Re: [perl #47027] Documentation: BEGIN, END docs in wrong section
[In reply to]
> On Sat, May 05, 2012 at 09:15:29AM +0100, Denis Howe wrote:
> > On Fri 2012-05-04 07:13:17, denis.howe [at] gmail wrote:
> > > these are *subroutines*.
> > So why does the doc say that it is not good style to prefix them with
> > "sub"? Because they don't behave like subroutines in any way - you
> > can't call them, they don't take arguments or return anything. (In
> > fact the option to prefix them with sub sounds like a confusing,
> > historic wart that should be retired.)
> Not quite true. The default array for shift is on @_, not @ARGV, inside
> Yes, @_ is empty. But if you use shift; expecting it to be on @ARGV, you
> be confused. This is a trap I've fallen into.
> > > There is an argument to be made that they belong in perlsub
> > Only if you can convince us they are subroutines.
> You're not phrasing that correctly. They *are* subroutines. That's what
> are internally.
> What matters is whether from a language user perspective whether they are
> far from subroutines that they have more in common with some other part of
> the language than with subroutines.
> Nicholas Clark
I can have arbitrarily many BEGIN blocks in the same package, and they are
called in the order that they are declared. I can only have one DESTROY
subroutine in a given package, and only the last executed definition is
used when I call it. This makes named blocks just that: blocks, not
If BEGIN and other named blocks are implemented as subroutines, with sundry
ramifications on @_ and other things (caller?), that is an implementation
detail, or even an implementation wart. These warts (if so deemed) should
definitely be made clear in the docs, or done away with if possible.
FWIW, I have round tuits, maybe even enough to write docs for said wart,
but not nearly enough to modify Perl's handling of these blocks.
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan