Up to Main Index Up to Journal for December, 2023
JOURNAL FOR MONDAY 18TH DECEMBER, 2023
______________________________________________________________________________
SUBJECT: Domain transfer complete, tinkering with Mere maps
DATE: Mon 18 Dec 16:13:11 GMT 2023
FYI: I am not affiliated with Mythic Beasts, they are just a great company.
The deed is done and the last vestiges of WolfMUD at 123-reg are gone. If
something is working you usually just leave it alone, it’s simply less hassle.
In this case 123-reg ticked me off enough that it motivated me to finally move
everything away from them.
The process of transferring the wolfmud.org domain to Mythic Beasts[1] was
quite painless. Record all my settings from 123-reg, get a transfer code,
initiate transfer at Mythic Beasts, setup new DNS settings…
Website was back up and running. I think I had about 15 minutes of down time.
Then I had to contact Mythic Beasts support as I had some questions. By this
time it was nearly 8:30pm on a Saturday, but within an hour and a half I had
the answers I needed.
However, the Git repositories were off-line and code.wolfmud.org wasn’t
responding. Another quick email to support just to confirm a DNS setting, now
nearly 10pm. I had an answer within 20 minutes and I could clone the WolfMUD
repository :)
All in all, start to finish, I’d transferred the domain, setup DNS, setup
email (with SPF and DKIM) and tested everything within 5 hours. Most of that
was waiting for the domain to transfer. I’ve even managed to set a Certificate
Authority Authorization (CAA) DNS record for wolfmud.org which I couldn’t do
with 123-reg last time I checked.
When registering domains with Mythic Beasts you get access to dynamic DNS. I
currently use NoIP[2] for dynamic DNS, and have no issues with their service
at all. However, using the Mythic Beasts service lets me use a sub-domain on
my main domain, instead of a sub-domain on a NoIP main domain. I’d actually
worked around this by pointing a CNAME to the NoIP domain, clunky but worked.
In other news I’ve been fiddling with Mere and trying to make the static
analysis work. The main issue at the moment, once again, involves maps. A map
element can be any of the Mere types — not to be confused with the Mere type
any. This means you don’t know the type of an element when you retrieve it.
Currently the concrete type of the element is returned. However, I think it
would make more sense for the returned element to be of type any. This would
then require a conversion to a specific type before use.
Some simple examples:
sm := [string] "a" "ant", "b" "bat", "c" "cat", "x" 3, "y" 5
println literal sm["a"] // displays: any("ant")
println string sm["a"] // displays: ant
println int sm["x"] + int sm["y"] // displays: 8
It would mean removing the “!any” construct as it returns an indeterminable
type. The range-next loop would also need to be modified to make the returned
value in the loop be of type any.
This is quite a change and I’m not sure it’s a good one or not. The code would
be more readable as you would know what type to expect from a map element. It
would require more typing when writing code. Maintenance could be a bit of a
problem — to change a type in a map you’d need to update all of the type
decorations.
The alternative would be to make maps less useful by defining the element
types like Go does: [string]string, this is a map with string keys and string
elements. Then for the case where you want a general map you could define
[string]any, a map with string keys and type any elements — which would then
require the unboxing as detailed above.
This means my map handling would go from 7 combinations to 49 combinations and
make the operator table huge, it already has 830 methods. However, in the long
run it may actually make map handling easier.
Hrm, I think I need to go and do some more experiments…
--
Diddymus
[1] Mythic Beasts: https://www.mythic-beasts.com
[2] No IP: https://www.noip.com
Up to Main Index Up to Journal for December, 2023