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