A couple of comments on the first post suggested that I look into the command-line bookkeeping application ledger, or indeed, its Haskell version hledger. They look very interesting, but rather hard to wrap my head around. So though I'm going to bear them in mind for later, I'll carry on doing these sketches till I understand the problem space better, at which point, perhaps I'll either a) steal some ideas from them, or b) realise they are undoubtedly the way forward and start using them.

I used Module::Starter to retrospectively turn this project into something I can release as a distribution to CPAN, with docs, tests, a Makefile, and so on.

module-starter --module=Beans --mi --author=osfameron --email=osfameron@cpan.org

This also creates some skeleton docs, so I've gone in to add a few actual notes (mainly just pointing at this blog), and to delete a few sections that module-starter puts in by default:

AnnoCPAN
(I don't think this is particularly useful, and don't see the need to advertise it from my module, as it's already linked to from search.cpan.org)
CPANratings
This is useful, but again, it's already linked to from search.cpan.org. Why should I link to it from my module? Should I also include buttons to pimp it on reddit and digg?

Then I added some tests in t/01-basic.t, for example: 

my $item = Beans::Item->new(
    name     => 'Mortgage',
    value    => 500.00,
    due_date => '2009-10-01',
    comment  => 'Home sweet home',
    tags     => [qw/ mortgage foo bar /],
    );

ok $item, 'Object created successfully';

is $item->name,  'Mortgage',      'Name ok';
is $item->value, 500,             'Value ok';
is $item->due_date->month, 10,    'Date ok';

All very noddy stuff, but it helped me find a bug in the version I'd blogged earlier! I hadn't told the date fields to use the coercion I'd set, so the above code failed, complaining quite rightly that '2009-10-01' isn't a DateTime object!

So I amended the date fields like so: 

     has due_date  => ( isa      => DateTime, 
                        is       => 'rw', 
                        required => 1, 
                        coerce   => 1,
                      );

and all was again well. Yay for failing tests! This brings me to a suggestion from John Napiorkowski to use MooseX::Types::DateTimeX to get my coercion for free. This does indeed work, and I've changed the code to use it, though it doesn't by default use DateTime::Format::Natural — we'll come back to this later.

While we're looking at types, let's fix the crufty implementation of tags. We've currently got an ArrayRef[NonEmptyStr], but really, we don't want an Array, because we want to be able to:

  • Check whether a given tag is active
  • Enable a tag (without duplicating it if it's already present)
  • Delete a tag.
These aren't so much features of arrays as of hashes, or, even better, sets. I was about to enter a rabbit hole of implementing using a hash and ::Meta::Attribute::Native::Trait:: when Stevan suggested Set::Object and its wrapper MooseX::Types::Set::Object.

This changes our code to: 

    has tags      => (
                       isa      => 'Set::Object',
                       is       => 'rw',
                       accessor => '_tags',
                       coerce   => 1, # also accept array refs
                       handles => {
                           tags       => 'members', # random order
                           add_tag    => 'insert',
                           remove_tag => 'remove',
                           has_tag    => 'member'
                         },
                     );

which we can test like so: 

is_deeply [ sort $item->tags],
    [qw/ bar foo mortgage /],     'Tags ok'
        or diag Dumper($item->tags);

ok $item->has_tag('foo'),         'Has tag foo';
ok $item->has_tag('bar'),         'Has tag bar';
ok $item->has_tag('mortgage'),    'Has tag mortgage';
ok ! $item->has_tag('baz'),       'Nonexistant tag baz';
$item->add_tag('baz');
ok $item->has_tag('baz'),         'Now has baz';
$item->remove_tag('foo');
ok ! $item->has_tag('foo'),       'Now lost tag foo';

Set::Object's members function returns the contents in hashed order (i.e., effectively random), but given that we know our "objects" are actually strings, I'd prefer them in sorted order, which would simplify the is_deeply test above. We could do this as a method instead, or possibly use around to sort the results, but we'll come back to this soon!