So today for the third episode of this diary, and after Diary of a Zydeco experiment - E02 - History, I would like to share a nice error message that I encountered while working on the modeling of my project. It can look strange to be happy about encountering an error message, but this one made my life really easier. It is still not about Zydeco directly but about one of the stable technology it relies on. Please don't look too deeply at the examples, they are mostly sarcastic but not very well structured on the OO side for now.

So we have this role, that summarize very naively what a Buyer can do:

    # lib/Wildlife/Behavior/Buyer.zydeco.pm
    role Buyer {
      requires money;
      method acquire ( Num $price ) {
        say "I bought !";
      }

      method sale ( Num $price ) {
        say "I sold !";
      }
    }
[download]

There is also an Exhibit role, that I will show only for the fun, but it is mostly distraction at this point:

    # lib/Place/Behavior/Exhibit.zydeco.pm
    role Exhibit {
      has exhibition ( type => ArrayRef );
      has artist ( type => ArrayRef );
      has artwork ( type => ArrayRef )
      method display {
        say "Shoooow";
      }
    }
[download]

Then we have a Gallerist class, that consumes the Buyer role. You will maybe notice that there is a tiny mistake in this class (we'll come back a bit later on the mistake so don't look too much):

    # lib/Art.pm
    package Art {

      use Zydeco;

      class Place {
        has space;
        include Place::Behavior::Exhibit;
        include Wildlife::Behavior::Buyer;

        class Gallery with Exhibit, Buyer {
          has artwork (  type => ArrayRef );
          has artist (  type => ArrayRef );
          has event ( type => ArrayRef );
          has owner;
          has public;
        }
      }
    }
[download]

A test:

    # t/gallery.t
    use v5.16;
    use Test::More;
    use Art;

    my $gallery = Art->new_gallery(
      space => 1000,
      exhibitions => [ "Foo", "Bar" ],
      owner => "Arty Person",
      money => 10_000_000 );

    ok $gallery->does('Art::Exhibit'), 'Gallery does role Exhibit';
    ok $gallery->exhibitions, 'Gallery got an exhibitions attribute';
    ok $gallery->owner, 'Gallery got an owner';

    can_ok $gallery, 'acquire';
    can_ok $gallery, 'sale';
[download]

Let's run it! But it won't go very well.

    smonff@padi:~/projects/Art-World$ prove -lv t/15_gallery.t
    t/15_gallery.t .. Can't apply Art::Buyer to Art::Gallery - missing
+ money at /home/smonff/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl
+/5.32.0/Moo/Role.pm line 307.
    BEGIN failed--compilation aborted at (eval 269) line 1.
     at /home/smonff/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.
+32.0/B/Hooks/EndOfScope/XS.pm line 26.
    Compilation failed in require at t/15_gallery.t line 3.
    BEGIN failed--compilation aborted at t/15_gallery.t line 3.
    Dubious, test returned 2 (wstat 512, 0x200)
    No subtests run

    Test Summary Report
    -------------------
    t/15_gallery.t (Wstat: 512 Tests: 0 Failed: 0)
      Non-zero exit status: 2
      Parse errors: No plan found in TAP output
    Files=1, Tests=0,  2 wallclock secs ( 0.03 usr  0.00 sys +  2.00 c
+usr  0.10 csys =  2.13 CPU)
    Result: FAIL
[download]

What I want to focus on is the Can't apply Art::Buyer to Art::Gallery - missing money part.

The error message is launched by a croak call in the _check_requires() method of Role::Tiny.

    croak "Can't apply ${name} to ${to} - missing ".join(', ', @requir
+es_fail);
[download]

Once we add the right attribut to the Gallery class, everything goes well:

    class Gallery with Exhibit, Buyer {

      has artwork (  type => ArrayRef );
      has artist (  type => ArrayRef );
      has event ( type => ArrayRef );
      has owner;
      has public;
      has money;
      ...
  }
[download]

And we run the tests again:

  smonff@padi:~/projects/Art-World$ prove -lv t/15_gallery.t
  t/15_gallery.t ..
  ok 1 - use Art;
  ok 2 - Gallery does role Exhibit
  ok 3 - Gallery got an exhibition attribute
  ok 4 - Gallery got an owner
  ok 5 - Art::Gallery->can('acquire')
  ok 6 - Art::Gallery->can('serve')
  ok 7 - Art::Gallery->can('sale')
  1..7
  ok
  All tests successful.
  Files=1, Tests=7,  2 wallclock secs ( 0.03 usr  0.00 sys +  2.30 cus
+r  0.16 csys =  2.49 CPU)
  Result: PASS
[download]

We actually don't even need to check the attributes in details.

What I found amazing is how the error message makes sense. It just tells what should be done to fix the problem: adding a money attribute to the Gallery class. But more than that, it have a deeper meaning, that is exactly the point og this project. I mean you wouldn't have an art gallery with zero money would you? This is what I call efficient and reliable object oriented programming thanks Zydeco making a great use of the stable technologies it is built on (like Role::Tiny).

So far, my overall use of Zydeco is very satisfactory during the application modeling phase. Some could say that I could draw some class diagrams and not coding, but the Zydeco use is so easy and non-verbose that it really make possible to focus ont the modeling and not on the coding: focusing on listing attributes, methods, roles and their relationship, not on the implementation.

Next episode is mostly news from the brand new 2021 year...