lichtkind

If you write any software package, you have to document it. This simple truth drives more than few developers into despair. But there is also a way to craft good documentation and make the writing of it a useful part of the development. This is the closing part about authoring a Perl 6 module and Math::Matrix in particular (part: one, two, three, and four).

While reflecting on how to write a good Perl 6 module, I thought a lot about how to properly name my methods. In this text I want to summarize what served me, which is a direct continuation of the last part, where I wrote about when it is helpful that methods share one name.

In this guide about what to consider when writing a Perl 6 module, we (after part I and part II) will reach Perl 6's great power of signatures. They enable a feature, that is very often used in Perl 6 (internally and externally). Here are my arguments when the usage of MMD makes the most sense.

In this series of articles I reflect and expand on a talk I gave this year in Glasgow were I spoke about writing Perl 6 modules in general and Math::Matrix in particular. Part I was about data types I used or wanted to use, because my approach is it to think first about data structures and built later the code around that. It is also crucial because this module basically provides the user a new data type.

At TPC in Glasgow I held two talks (slides and Video stored or linked on my domain as linked on conference site) about my module Perl6::Math::Matrix. To me the most interesting parts of this talk were musings about how to write a good API in and for Perl 6. And since I already got from the audience a lot of good suggestion(, which are all implemented by now [by the critic or me]), I will write here also a series of posts about this topic and maybe get some inspirations more.