Up to Main Index                           Up to Journal for January, 2017

                     JOURNAL FOR SUNDAY 8TH JANUARY, 2017
______________________________________________________________________________

SUBJECT: Jars of Records and multiple fields
   DATE: Sun  8 Jan 23:45:22 GMT 2017

It’s Sunday evening and I just realised I hadn’t written anything in the
journal yet this year. So here we go, first entry to kick off 2017.

Last week was the first week back to work after the Christmas break. As a
result I’ve had a lot of catching up to do. But how can that be? If everyone
is spending time with family over the holidays how can I have a stuffed inbox
to return to? There were also several jobs I needed to complete that should
have been completed before Christmas which didn’t help matters — oops!

A long week of long hours and working late.

I did manage to get some coding done on WolfMUD — mainly because I really
needed the break. You can only code for so long in PHP before the insanity
starts to set in :( PHP is not a nice language to code in and it’s only
productive because you can haphazardly slap code together willy—nilly and the
interpreter will take a best guess at what it thought you wanted. I speculate
that the reason there are so many PHP frameworks is that they are all trying
to insulate the programmer from the underlying PHP!

Back to WolfMUD, Go and sanity.

I’ve recently rewritten the RecordJar Read method as the previous version had
a number of issues and painful corner cases. Considering how long the previous
version took to write the new version practically typed itself by comparison.

But then I had to fiddle with it.

What I wanted to do was add multiple field support. This would be handy when
implementing mobiles. Mobiles have actions. Take the rabbit as a simple
example. It has two random actions:

  - The rabbit hops around a bit.
  - You see the rabbit twitch its little nose, Ahh...

Currently there is no easy way to represent this. One approach would be to use
multiple records:


  %%
      Ref: M1
     Name: a rabbit
    Alias: rabbit
  Actions: M1A1 M1A2

  It's a small white, fluffy Bunny Rabbit. Not a pocket watch in sight, and
  it doesn't seem to be late for anything!
  %%
      Ref: M1A1
   Action: The rabbit hops around a bit.
  %%
      Ref: M1A2
   Action: You see the rabbit twitch its little nose, Ahh...
  %%


However this seemed clunky and long winded. What I really wanted to do was add
support for multiple fields. An example of what this would have looked like
would be:


  %%
      Ref: M1
     Name: a rabbit
    Alias: rabbit
   Action: The rabbit hops around a bit.
   Action: You see the rabbit twitch its little nose, Ahh...

  It's a small white, fluffy Bunny Rabbit. Not a pocket watch in sight, and
  it doesn't seem to be late for anything!
  %%


Very simple. If you want two actions you just specify two actions.

I implemented this and it worked. But now I had several issues. The Record in
a RecordJar was now map[string][][]byte instead of just map[string][]byte.
That meant that every attribute had to be able to deal with possibly multiple
values even if they only expected one — [][]byte instead of []byte. It also
meant that unmarshalling attributes would be more complicated. In short the
new RecordJar worked but everything else started to unravel :(

The easiest alternative I could think of was to use a symbol separated list:


  %%
       Ref: M1
      Name: a rabbit
     Alias: rabbit
   Actions: § The rabbit hops around a bit.
            § You see the rabbit twitch its little nose, Ahh...

  It's a small white, fluffy Bunny Rabbit. Not a pocket watch in sight, and
  it doesn't seem to be late for anything!
  %%


Here I’ve used the section symbol (§) as the separator. It would work and
seems clean, but awkward to type for some — in Vim it’s Ctrl-kSE in insert
mode. By looking at the first symbol in the list and using that as the
separator we can let the user/author use any symbol they want. Just like the
existing separator in exit pairs, for example E→L2.

The actions would not have to be on separate lines, but I think it aids
readability:


   Actions: § The rabbit hops around a bit. § You see the rabbit twitch its
            little nose, Ahh...


Using this method I might be able to implement vetoes at long last as well.
Something long the lines of:


  Vetoes: § GET→The rabbit does not appreciate being picked up.
          § PUT→The rabbit does not want to be put anywhere.


This combines using a separator with elements that also use a syntax similar
to the existing pair lists used to specify exits.

Maybe I should reserve the colon (:) as a separator that everyone should use?
Would that make it easier? Something like:


   Actions: The rabbit hops around a bit.
          : You see the rabbit twitch its little nose, Ahh...

    Vetoes: GET→The rabbit does not appreciate being picked up.
          : PUT→The rabbit does not want to be put anywhere.


It looks neater. It would mean you couldn’t use a colon in the text itself —
unless I also added a way to escape the colon. Or added a rule like “a leading
colon will be used as a value separator for fields that support it”.

Something for me to be mulling over until my next coding session.

As always if anyone has comments or ideas I’d love to hear them:
diddymus@wolfmud.org

--
Diddymus


  Up to Main Index                           Up to Journal for January, 2017