Up to Main Index Up to Journal for October, 2018 JOURNAL FOR FRIDAY 19TH OCTOBER, 2018 ______________________________________________________________________________ SUBJECT: Thoughts on the recordjar package + update DATE: Fri 19 Oct 19:52:06 BST 2018 About a year ago I made the decision to split up the recordjar package and to move the encoder and decoder into their own sub-packages. At the time the reasoning went along the lines of: At the moment using the recordjar encoder and decoder is quite verbose: recordjar.Decode.Duration(data) recordjar.Encode.Duration(data) There is also the issue of only exporting functionality needed by other packages. However this means that the useful functions are not visible by default in the go doc. This change moves the encoder and decoder into their own packages. It drops the exported Decode and Encode package level variables. The unexported decode and encode types are dropped and their methods turned into functions. This allows for less verbose usage of the encoder and decoder: decode.Duration(data) encode.Duration(data) The functions for both the decoder and encoder are exported and visible in the go doc. That was from Wednesday, 11th October 2017, commit e2cc4bc2d2. After working with the encoder and decoder a lot recently I think I only partially fixed the issues. My thinking now is that there should be a package called wrj (WolfMUD recordjar) which is a specialised version of recordjar, and which has the encoder and decoder functionality. My current thinking is based on actual usage, hindsight and looking at the encoding package in the standard library. I’m slowly edging towards the idea of a wrj package being at the same level as the recordjar package, as opposed to a sub-package of the recordjar package. Simply because the recordjar package is independent. The encoding and decoding is dependant on the syntax imposed for .wrj files — a plain record jar file only has records, field name/value pairs, comments and a free text block. What the data value for a specific field means, and what format it should be in, is usage specific. I’m not planning on making any big, sweeping changes right now — I need to finish testing the rest of the WolfMUD packages. However, I wanted to put my thoughts somewhere so that I wouldn’t forget my ideas when I revisit the code. I also though people might want to give some feedback? In the meantime, I’ve just updated the public dev branch. The recent changes are mostly cleaning up tests and providing better test data. There is one fix to encode.StringList, the results should be sorted. Only 12 days left till Halloween… /\oo/\ -- Diddymus Up to Main Index Up to Journal for October, 2018