view release on metacpan or  search on metacpan

lib/Class/Std/Slots.pm  view on Meta::CPAN

    }

That's not bad - but we had to create a subclass - and we'd have to arrange for it
to be created instead of a C<My::Downloader::Better> anytime we want to use it. If
displaying the progress involved updating a progress bar in a GUI we'd need to
embed a reference to the progress bar in each instance of C<My::Downloader::Verbose>.

Instead we could extend C<My::Downloader::Better> to call an arbitrary callback via
a supplied code reference each time C<progress()> was called ... but then we have to
implement the interface that allows the callback to be defined. If we also want
notifications of retries and server failures we'll need still more callbacks. Tedious.

Or we could write C<My::Downloader::Lovely> like this:

    package My::Downloader::Lovely;
    use Class::Std;
    use Class::Std::Slots;
    {
        signals qw(
            progress_update
            server_failure

lib/Class/Std/Slots.pm  view on Meta::CPAN

    # Now the clever bit - hook them together. Whenever the
    # progress_update signal is emitted it'll call
    # $pretty->update_bar($done);
    $lovely->connect('progress_update', $pretty, 'update_bar');

    # Do the download with style
    $lovely->do_download();

We didn't have to subclass or modify C<My::Downloader::Lovely> and we didn't have to clutter its
interface with methods to allow callbacks to be installed.

Each signal can be connected to many slots simultaneously; perhaps we want some debug to show
up on the console too:

    use My::Downloader::Lovely;
    use Pretty::ProgressBar;

    my $lovely = My::Downloader::Lovely->new();
    my $pretty = Pretty::ProgressBar->new();