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