This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.
Type::Tiny has been knocking around in some shape or another for almost a year now. It’s certainly grown a lot since its first commit. The distribution probably no longer merits the “Tiny” name, though the lead module itself is still fairly lean. There are over 80 distributions that list it as a pre-requisite in some way or another, and more still that depend on those.
So I think it’s time to begin planning to stabalize the API. Right now, my plan is:
- Achieve 100 reverse dependencies.
- Complete the testing TODO list.
- Finish documenting which parts of the API are considered unstable/experimental, and won’t be covered by the stability policy.
- Close any remaining RT tickets.
Not necessarily in that order.
So, why am I telling you all this?
Well, the primary use case for Type::Tiny is attribute validation in Moose-style class builders, but it can be used for other purposes too: sub parameter validation, switch-like statements, or tied arrays. If you’ve found a novel use for Type::Tiny, I’d like to hear about it. Together maybe we can add some code to the Type::Tiny test suite to make sure your use case is covered.
The stability policy is a guarantee that (with some small exceptions) any changes which would break Type::Tiny 1.000000’s test suite will require an extensive notice period. The more use cases it covers, and the more obscure parts of the API get tested, the better that guarantee becomes.
