At its core, dependency injection is a formalization of the design principle "Don't hard-code your dependencies." Consider the code:

sub fetch
{
    my ($self, $uri) = @_;
    my $ua           = LWP::UserAgent->new;
    my $resp         = $ua->get( $uri );

    ...
}

That's not bad code by any means, but it's a little too specific and a little less generic due to the presence of the literal string LWP::UserAgent. That might be fine for your application, but that hard-coding introduces a coupling that can work against other uses of this code. Imagine testing this code, for example. While you could use Test::MockObject to intercept calls to LWP::UserAgent's constructor, that approach manipulates Perl symbol tables to work around a hard coded dependency.

An alternate approach uses a touch of indirection to allow for greater genericity:

use Moose;
has 'ua', is => 'ro', default => sub { LWP::UserAgent->new };

sub fetch
{
    my ($self, $uri) = @_;
    my $ua           = $self->ua;
    my $resp         = $ua->get( $uri );

    ...
}

Now the choice of user agent is up to the code which constructs this object. If it provides a ua to the constructor, fetch() will use that. Otherwise, the default behavior is to use LWP::UserAgent as before.

Adding one line of code and changing one line of code has provided much more flexibility.

An alternate approach is to allow setting ua through an accessor instead of a constructor, but as far as I can tell the only reason to do this is if you're stuck in The Land of the Java Bean Eaters.

While the existing literature on inversion of control and dependency injection tends to throw around big words which have the effect of obfuscating rather than enlightening, the basic concepts is simple. You've probably already done it. Now you know what it's called and why it's useful, and probably also can find ways to use it where it helps.

(See also: how you select a DBD with DBI.)

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.

Sometimes that ease moves the problem around, which reinforces the notion that the only two hard problems in computer science are naming and caching. To abuse that truism, once I've found a workable solution, the hard part is figuring out what to call it and how to make it available to other people.

Take the flash feature of Catalyst's Catalyst::Plugin::Session. It resembles the stash, in that you can store and retrieve information in and from the flash, but that data is only available until the first request which uses it. This is incredibly handy for user notifications, such as "You missed a required entry field!" or "Your interaction succeeded!", especially when combined with the Humane JS library.

My controller actions have a pattern:

sub edit :Chained( 'get_widget' ) :PathPart('edit') :Args(0)
{
    my ($self, $c) = @_;

    return unless lc $c->req->method eq 'post';

    my $params = $c->req->params;
    my $widget   = $c->stash->{widget};

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        push @{ $c->flash->{messages} }, 'Updated widget!';
    }
    catch { push @{ $c->flash->{errors} }, $_ };

    return $c->res->redirect(
        $c->uri_for( $c->controller( 'Widgets' )
          ->action_for( 'index' ) )
    );
}

Yet every time I write that code, it feels slightly wrong, as if I'm violating encapsulation by updating the variable behind the flash directly. It's also prone to typos and has the whiff of violating the Law of Demeter.

I prefer instead to write:

    try
    {
        $widget->$_( $params->{$_} ) for $widget->editable_fields;
        $widget->update;
        $c->add_message( 'Updated widget!' );
    }
    catch { $c->add_error( $_ ) };

... where my actions don't have to know about the internals of how the flash stores its data, where I don't have the possibility of stomping all over the array references accidentally, and where I can replace syntax (the grotty Perl 5 reference syntax!) with a method which describes my intent.

The simplest way to make this work is:

package Catalyst::Plugin::Session::FlashMethods;
# ABSTRACT: add flash-manipulation methods to Catalyst::Plugin::Session

use parent 'Catalyst::Plugin::Session';

use Modern::Perl;

sub add_message
{
    my $self = shift;
    push @{ $self->flash->{messages} }, @_;
}

sub add_error
{
    my $self = shift;
    push @{ $self->flash->{errors} }, @_;
}

1;

... and load it in my applications with:

use Catalyst::Plugin::ConfigLoader;
use Catalyst::Plugin::Static::Simple;
use Catalyst::Plugin::Session::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    ConfigLoader
    Static::Simple
    Session::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

This approach has (at least) two problems. First, while I'm happy to make this code available to other developers, I don't want to add any difficulties to use other plugins which may themselves extend or modify Catalyst::Plugin::Session.

Second, this code is awfully specific to my own uses. I believe those uses could help other people, but why solve a problem so specific when genericity and wider applicability are possible?

Rephrasing the problem might help.

I have a hash. I want named methods to store application-specific data in that hash. I would like the ability to customize that set of methods methods without hard-coding them, so as to produce a component that multiple people can reuse in multiple applications.

You can see why a big bag of untyped stuff (a hash) is useful.

What I really need is a way to say "My application will use these and only these specific elements of the flash, so please produce methods for them." Fortunately, I have one in MooseX::Role::Parameterized. The consumer of this code looks like:

package MyApp::Catalyst::Plugin::FlashMethods;
# ABSTRACT: role to add flash-manipulation methods to Catalyst app

use Moose;

extends 'Catalyst::Plugin::Session';
with 'Catalyst::Plugin::Role::FlashMethods'
    => { flash_elements => [qw( message error )] };

1;

... and it gets enabled in my Catalyst application with:

use MyApp::Catalyst::Plugin::FlashMethods;
use Catalyst::Plugin::Session::State::Cookie;
use Catalyst::Plugin::Session::Store::FastMmap;

use Catalyst qw/
    -Debug
    ConfigLoader
    Static::Simple
    +MyApp::Catalyst::Plugin::FlashMethods
    Session::State::Cookie
    Session::Store::FastMmap
/;

... which consumes the parametric role:

package Catalyst::Plugin::Role::FlashMethods;

use MooseX::Role::Parameterized;

parameter 'flash_elements', isa => 'ArrayRef[Str]', required => 1;

role
{
    my $p = shift;

    for my $element (@{ $p->flash_elements })
    {
        method "add_${element}" => sub
        {
            my $self = shift;
            push @{ $self->flash->{ $element . 's' } }, @_;
        };
    }
};

1;

This code does have some naïve in it. In particular, it ought to use a smarter pluralization scheme. As well, the interface bothers me in two places. I'm not sure that the module's name is correct. I also don't particularly like that using this role means creating a new class of ~10 lines to make the code available as a Catalyst plugin (though how one might expand Catalyst's import() to understand how to reify a parametric role given the appropriate parameters is beyond my language design skills today).

Then again, my ~10 line plugin which consumes this role does work across my multiple Catalyst applications, at the cost of one more file and nine more lines of code altogether. The ratio of code per method decreases substantially with each new method I add, though.

I had originally intended to improve stash handling in this fashion, but but that's much more work. Neither Catalyst's core nor any other plugin I currently use rely on the presence of flash, so the scope of this work was much smaller. Even if they did, this approach does not prevent anything else from poking into the flash for good or ill.