lichtkind

In this guide about what to consider when writing a Perl 6 module I want after part I and part II turn to Perl 6's great power of signatures and how to use MMD (multi method dispatch) the right way.

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 my module 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 with a new data type. (You might want to reread it - I expanded it to twice the size after publishing it.)

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.

After part one (main idea), two (prototypes) and three (sane boundaries of responsibility), I head toward the big picture. How does a project head coordinates planning under a "complete programming" (c) (tm) methodology.

There are many more details about planning in CP I left out for now, because it is already a lot to think about. In the next part I will write about the role of software tests in CP.

If there would be an election for the single greatest Perl 6 feature, many would select the box for grammars and others would root for concurrency/async (as expressed in several articles here and elsewhere). Roles and types might be also strong contenders. Here is why I would pick: none of the above, even I like all of them very much.