Up to Main Index Up to Journal for August, 2020
JOURNAL FOR SATURDAY 1ST AUGUST, 2020
______________________________________________________________________________
SUBJECT: Ongoing fixes and some thoughts moving forwards
DATE: Sat 1 Aug 21:48:39 BST 2020
Still working on sorting out the save/load issues for in-flight events. Due to
a subtle change in what is now considered a collectable item by players it’s
taking longer than anticipated.
Previously players could only keep items that didn’t have an origin. This
meant they could keep non-unique, non-spawnable items. However, now that
spawning is working correctly it is possible for players to keep spawnable
items that they have in non-spawnable containers. A subtle change that I
didn’t notice until working on the save/load issue. While looking to update
the notion of what is or isn’t collectable I found a number of instances where
assumptions had been made in the code about the collectability, spawnability
and origins of items. In short it’s a bit of a mess :(
Fixing all of the recent problems has not been fun. Working on WolfMUD has not
been fun. If working on WolfMUD isn’t fun I won’t want to do it any more. Fret
not! I’m going to continue with WolfMUD, I just need to improve the current
situation.
Will I scrap everything and start over? I’ve considered it, a lot, but no.
Way back when, I thought that using interfaces for all of the attributes was a
good idea. For example, it meant that multiple attributes could contribute to
an item’s description by implementing the Description interface. An example of
this is the Door attribute — a door will add whether it is open or closed to
its description. It was also intended to make it easier for other developers
to add their own, possibly specialised for their MUD, implementations of
attributes to add or change functionality.
Using interfaces all over the place has some drawbacks. You can’t access a
struct’s fields — you end up adding setters and getters, even for simple
values. There is also the subtle issue of nil and (*T)(nil). WolfMUD uses
typed nil values a lot, but it’s bitten me in the arse far too many times. If
you’re not familiar with the issue it’s due to the fact an interface may be
nil with no dynamic type or concrete value, or it may have a dynamic type but
its concrete value is nil[1].
After a lot of cogitating I realise that only the base Attribute type needs to
be an interface. This allows a Thing to have a slice containing any Attribute.
Only the Description and Vetoes attribute interfaces are actually used for
their intended purpose — and vetoes need a rework to be more useful…
There is also the issue of tests and testing. Testing in WolfMUD is quite a
hit and miss affair. If I had tests for everything then sorting out issues
would be much easier. I’ve tried many times to add more tests, however adding
tests to a huge codebase after it’s been written is not a nice or easy job :(
My plan will be to rework all of the attributes, dropping the interfaces, and
giving each attribute its own sub-package under the attr package. “Hold on!”,
you say, “Give each attribute its own package!?”. Yup. If you look at the
godoc for the current attr package it is huge. The simplest way to break it up
is for each attribute to have its own package, if two or more attributes have
very similar functionality they may share a sub package. Plus each attribute
will have quite a few files: its source, documentation, possibly separate
source for helper or internal functionality, tests for everything, examples on
using the attribute. A good example here is the Inventory attribute where I
can move the specialised linked list implementation into its own file with
tests and documentation while still keeping it all under attr/inventory.
There will still be some attribute interfaces: Description, Vetoes and
Marshaler. However, interfaces will only used where it makes sense instead of
the plethora we have now. This also means that the ‘has’ package will go away.
As I rework and move each attribute into its own sub-package I plan on going
over the code with a fine toothed comb, reviewing documentation and comments,
writing examples and of course writing the all important tests. I plan to
simplify code where possible and remove any premature functionality — code
where I thought something might be needed or useful in the future, so “why not
add it now?”…
Once all of that is done I’ll start crawling all over the rest of the code.
Will this all take time? Yes. Will it make WolfMUD better? I hope so. Will it
make coding on WolfMUD fun again? I really hope so. I also hope it will make
it easier for other people to work on WolfMUD and either contribute or make it
their own. Ripping out the guts of WolfMUD and reworking it is not something I
do lightly and I have given it a lot of thought. If anyone else has thoughts
or ideas they would like me to consider during the revamp, drop me an email:
diddymus@wolfmud.org
First off, I need to fix issues and get v0.0.16 out to people.
--
Diddymus
[1] Developers usually discover this then their error is not nil, as covered
in the Go FAQ question “Why is my nil error value not equal to nil?”:
https://golang.org/doc/faq#nil_error
Up to Main Index Up to Journal for August, 2020