Introducing Perl6::Math::Matrix (Part 1: Data)
In this post, a developer explains a Perl module he created for working with data in your applications. Read on to get an overview!
Join the DZone community and get the full member experience.Join For Free
At TPC in Glasgow, I held two talks (slides and video stored or linked to 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 a lot of good suggestions from the audience (which are all implemented by now [by the critic or me]), I will write here a series of posts about this topic and maybe get some more inspirations.
As said during the talk, the basic design decisions were to see the Matrix as an array of arrays and a read-only data object. This allows me to cache all lazy evaluated, computation-heavy properties and not worry about them changing. It also forces me to create new Matrix objects when computing derivative matrices.
Such design decisions concerning the data structures are the most important to me. They also include thoughts about which data types we will need, which led me to my wish having a data type for a valid row and column index. This is not possible in Perl 6 yet, but I talked with Jonathan and he seems to gets slowly convinced about the usefulness of what I would call class types (a subset that can check against attribute data). It is not about inventing strange things but all the methods in the code that have to call a checker method, that tests if an index is valid is a big code smell to me.
Last but not least, the cells of the Matrix are of the type Numeric, which is the umbrella for all (you may have guessed it) numerical types. As part of my talk, we had a dispute between some audience members about the demand that Bool should be an allowed cell type. As a result, we found out that Bool is already included in Numeric (but converts to Int, when .Numeric is called on the value, since its just an ordinary enumeration [False, True]). The other end of the spectrum (widest type) is Complex, which is very good to have since it is used by mathematicians and some matrix properties, which only makes sense if you allow complex values. In some cases (which will be the topic of some later part), I will recognize the types Bool, Int, Num, Rat, FatRat and Complex and treat them differently, but in ordinary signatures Numeric will be used, when dealing with single call values.
Published at DZone with permission of Herbert Breunung, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.