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 ]

abw (998)

abw
  (email not shown publicly)
http://wardley.org/

Andy Wardley is the author of the Template Toolkit and various other modules.
+ -

  Comment: Badger::Debug (Score 1) on 2009.11.05 6:33

by abw on 2009.11.05 6:33 (#71043)
Attached to: My favourite Perl Design Pattern
<plug>

I also use the $DEBUG/DEBUG idiom in pretty much every module I write.  Being rather lazy I wrote Badger::Debug to do the job for me.

If you add the following to the top of your module:

    package Your::Module;
    use Badger::Debug default => 0;

Then you'll get both the $DEBUG package variable and DEBUG compile time constant defined for you (in this case, set to 0). The end result is almost exactly as per your example.

It also has a 'modules' option which you can use to enable debugging in various modules of your choice.

    use Badger::Debug modules => 'Your::Module';
    use Your::Module;

Now both $DEBUG and DEBUG will be set to 1 when Your::Module loads.

See http://badgerpower.com/docs/Badger/Debug.html#section_SYNOPSIS for further information.

Badger::Debug also plays nicely with Badger::Class.  This implements a number of useful idioms/patterns that I/we tend to use a lot.  For example:

    package Your::Module;

    use Badger::Class
        version   => 0.01,            # set $VERSION and VERSION
        debug     => 0,               # set $DEBUG and DEBUG
        base      => 'Badger::Base',  # set base class
        accessors => 'foo bar',       # define accessors
        mutators  => 'wam bam',       # define mutators
        utils     => 'blessed',       # import from [Scalar|List|Hash]::Util
        constant  => {
            PI    => 3.14159,         # define PI
        };
        # ...and so on...

All the above is "boring stuff" - supporting code that doesn't really relate to the core functionality of a module.  I don't like littering the first 100 or so lines of a module with various idiomatic bits of boilerplate code before I can get started on coding proper.  So  Badger::Class's raison d'etre is to sweep all that crufty stuff out of the way and hide it behind a nice simple interface.

</plug>
Read More 6 comments
Comments: 6
+ -

  Comment: Re:Badger::Class also makes this easy (Score 1) on 2009.09.16 3:45

by abw on 2009.09.16 3:45 (#70596)
Attached to: Anonymous objects as easily as hashrefs?

s/Auto/Anon/ # cut and paste fail

Read More 8 comments
Comments: 8
+ -

  Comment: Badger::Class also makes this easy (Score 1) on 2009.09.16 3:41

by abw on 2009.09.16 3:41 (#70595)
Attached to: Anonymous objects as easily as hashrefs?

The code sample you posted is almost there. You just need to create an anonymous package name instead of using __PACKAGE__. I would simply append the accessor names to the base class, e.g. Object::Anonymous_ding_wong_line

    sub new {
        my $class = shift;
        my %args = @_;
        my $self = { };
        my $name = join('_', $class, keys %args);

        for my $arg (keys %args) {
            # Store the given value
            $self->{$arg} = $args{$arg};

            # Create the accessor
            my $methname = $name . "::" . $arg;
            *{$methname} = sub {
                my ($innerself) = @_;
                return $innerself->{$arg};
            };
        }

        bless $self, $name;
    }

You can use Class::MOP::Class as chromatic notes. Or here's a similar thing using Badger::Class:

    package Class::Auto;

    use Badger;
    use Badger::Class 'class';

    sub new {
        my ($class, %self) = @_;
        my $name = join('_', $class, sort keys %self);
        class($name)->accessors(keys %self);
        bless \%self, $name;
    }

And here's an example of use:

    use Class::Anon;

    my $object = Class::Anon->new(
        x => 10,
        y => 20,
        z => 30
    );

    print ref $object, "\n"; # Class::Anon_x_y_z
    print $object->x, "\n"; # 10
    print $object->y, "\n"; # 20
    print $object->z, "\n"; # 30

Read More 8 comments
Comments: 8
+ -

  Comment: The root problem is interspersing code with POD (Score 1) on 2009.07.24 1:50

by abw on 2009.07.24 1:50 (#69593)
Attached to: Three things in Perl 6 that aren't so great

I have to say, I find the whole idea of POD interspersed with code quite loathsome. It appreciate all the reasons why it's a Good Thing (which boils down to keeping the docs as close to the code as possible), but it has so many drawbacks.

Most notably, it makes it hard to skim through the code when there's big globs of POD getting in the way. If I'm reading the source then it's code I want to concentrate on. If it's the end-user documentation that I want then I'll use perldoc or look at an HTML version of the docs.

It reminds me of the Bad Old Days when CGI scripts were written as an impenetrable mix of Perl code and HTML markup. We learned our lesson on this a long time ago - a separation of concerns is a good thing.

Another problem is that it forces you to write your POD to match the structure of your code or vice versa. This is wrong. The end-user documentation should be written from the perspective of someone wanting to use the module. This is an entirely separate thing from the way that the module is implemented internally. After all, that's what programming is about - creating "black box" abstractions that hide the details of the internal workings.

IMHO, code should be interspersed with comments to explain how the code works, and the end-user POD documentation should be placed at the end of the file. That way you don't have any of the problems with Perl code getting mixed up with POD. Things are badly wrong when you have to change your coding/indenting styling to fit in with the embedded documentation.

But that's just my HO, of course. Each to his/her own.

Read More 16 comments
Comments: 16
+ -

  Comment: Re:Who cares? (Score 1) on 2008.12.05 13:57

by abw on 2008.12.05 13:57 (#66284)
Attached to: Will you use Perl?

OK, I'll put the first stick in the ground.

I've put a few ideas together for a *.perl.org facelift. I chose use.perl.org as a starting because that was the original subject of discussion.

http://wardley.org/use.perl.org/test.html

Read More 48 comments
Comments: 48