Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

duncand (9318)

duncand
  (email not shown publicly)
+ -

  Comment: Re:try Carp::Always module (Score 1) on 2009.09.17 13:17

by duncand on 2009.09.17 13:17 (#70611)
Attached to: Help needed on a new 5.10 warning

I found that the effects of 'use Carp::Always' are global in scope, so I assume that loading it with -M on the command line will work as well as placement into code.

Read More 7 comments
Comments: 7
+ -

  Comment: try Carp::Always module (Score 1) on 2009.09.17 1:41

by duncand on 2009.09.17 1:41 (#70608)
Attached to: Help needed on a new 5.10 warning

I've found success with the Carp::Always module. All I have to do is say "use Carp::Always" at the top of my program, and any time an exception is thrown it includes a stack trace, which is great for diagnosing all the exceptions from 'use strict' or 'use warnings fatal'. That said it /may/ not be compatible with other attempts to override the signal handlers. I now make it common practice to put "use Carp::Always" at the top of all my module t/*.t files.

Read More 7 comments
Comments: 7
+ -

  Comment: yes, .p6 *is* outdated (Score 1) on 2009.08.15 17:27

A long time ago, .p6 was used for a short time, and then everyone wised up and avoided it. The proper way to name Perl 6 files is in the same manner as Perl 5 files, meaning .pl, .pm, .t, .pod, etc, and whether they are Perl 5 or Perl 6 is determined by the *content* of the files. If the file begins with something like "use 6.0;" rather than "use 5.008" then it is Perl 6; the latter means it is Perl 5. Using .p6 extensions is a terrible idea and anyone who returns to it should abandon the idea.

Read More 4 comments
Comments: 4
+ -

  Comment: Re:Methods and Pod not actual problem (Score 1) on 2009.07.24 12:22

by duncand on 2009.07.24 12:22 (#69607)
Attached to: Three things in Perl 6 that aren't so great

I agree that indenting methods relative to classes does look better, and I even do that myself some times.

Mainly I find that the indenting works best when individual classes are fairly small in the amount of code department, and similarly in those cases I generally don't use the dividing lines I mention.

Where I don't find indenting necessary is when classes are large or there are a number of large methods (ones that fill a screen or more), so that say you've got hundreds to thousands or more of code lines in one class. Generally speaking, indenting is more valuable within a local context than within a much wider context.

The main reason I have methods flush-left within larger classes is that horizontal screen real-estate is valuable and it seems a waste to not use a whole indent level for many thousands of code lines in order for exactly 2 lines to be further left than those. Especially since I strictly limit my line lengths to 75 characters and I use 4 character indents.

My practice has nothing to do with pod. In fact, I think mixing pod with code is a bad idea, and I put all my pod at the end of the file. While I keep my docs for classes and methods in the same order as their corresponding code in general, I believe in writing documentation for the users, and it can be more natural if it is separate; similarly the code can be easier to read.

I write # comments in the few cases where code actually should be explained for code-readers beyond what the user pod says.

So if people want to indent methods, I have no objection save ineffectualness and wasted space.

I will say though, that regardless of whether I indent methods in a class, I always indent other class contents like attribute declarations.

Read More 16 comments
Comments: 16
+ -

  Comment: Methods and Pod not actual problem (Score 1) on 2009.07.22 18:59

by duncand on 2009.07.22 18:59 (#69572)
Attached to: Three things in Perl 6 that aren't so great

There isn't actually a problem in the interaction of methods and pod, when you consider that the "problem" is based on false assumptions.

One false assumption is that methods have to be indented when you have a block class in order to be pretty; I disagree, and methods can be flush left just like their pod, so all pretty so far.

Another false assumption is that you can't have block classes in Perl 5, and so what worked for Perl 5 can't work for Perl 6; in fact you *can* have block classes in Perl 5, and I have been doing so for years in my newer CPAN modules.

Awhile ago I figured out a style that works well for both Perl 5 and Perl 6, that uses both block classes and flush-left methods. See http://cpansearch.perl.org/src/DUNCAND/Muldis-Rosetta-0.13.3/lib/Muldis/Rosetta/ Engine/Example.pm for an example.

You write a block class in Perl 5 like this:

{ package Austria; # class

#####

sub foo { ...
}

#####

} # class Austria

In Perl 6, it is exactly the same format:

class Austria {

#####

method foo (...) { ...
}

#####

} # class Austria

Like Perl 6, in Perl 5, surrounding the package declaration and following code with a brace pair makes it easy and elegant to have multiple package declarations in the same file, which I often exploit.

And if one follows a practice of putting visual lines between routine declarations to make them easier to read by deliniating where routines begin and end, one can also put them before the first and after the last method. This break removes any unpleasantness of the methods not being indented relative to the class block; this also gives us another indent-level of horizontal space to use within the routine.

-- Darren Duncan

Read More 16 comments
Comments: 16