I've like to propose adding a ROADMAP section to module documentation.
It would be a *short* summary of planned changes for future versions, noting what features would be removed or changed, or upcoming new features that will be added.
More detailed roadmaps should be put in a separate file (e.g. `ROADMAP` or `ROADMAP.md`) that should be referred to in the section. Or link to the roadmap if it's online.
I have been making a lot of changes to Graphics::ColorNames lately. The module has gone too long without any maintenance, and suffered from feature bloat.
Some notable changes that are already on CPAN:
- A switch to semantic versioning, e.g. v3.3.3.
- Some color schemes (Netscape, HTML, Windows) have been moved to separate modules.
- The Netscape and HTML schemes have been deprecated in favor of the WWW scheme.
- The X scheme has been updated to the latest X-Windows colors (which includes the CSS/WWW colors).
Roadmap for the future
I am planning on making the following changes:
Removing autoloaded method names for colors.
Removing the (deprecated) tied interface, but putting that in a separate module
Moving the color schemes into the Graphics::ColorNames::Schemes namespace, but provide an option to use the old namespace.
Change it to a Moo-based class
Removing support for Perls < v5.10.
I've created an experimental Type::Tiny library called Type::Const that coerces ArrayRefs and HashRefs into constants using Const::Fast.
Why?
When you have read-only attributes in Moo(se) classes:
has things => (
is => 'ro',
isa => HashRef,
);
While you can't change what hash reference things refers to, you can change the contents. This is fine:
$obj->things->{$key} = $val;
and there are good reasons for that.
But in other situations, you have built a table of data that you do not want changed. You can use this instead:
has things => (
is => 'ro',
isa => ConstHashRef,
coerce => 1,
);
The coercion means that any hash reference will be made read-only.