Hey all!
Lest you think I’ve been sleeping, I thought I’d post an update on all the incognito progress I’ve been making.
If you don’t want to read through my boasting about what I’ve been up to, the most salient announcement is this:
This is the last announcement. There will be no more as the upcoming
v0.11.0will be the last beforev1.0.0.
To commemorate that event and garnish more notice I’ll be starting a new thread, so many thanks to everyone that’s followed my progress here to date!
Now that that’s out of the way, here’s a wall of text:
v0.10.0
The observant of you might have noticed that I pushed out v0.10.0 a few months ago. It provided support for ElasticSearch (thanks for the contribution, @BDQ!) and the Elixir 1.5 Map.replace functions, and dropped support for Elixir 1.3 so it could use some newer language features internally (hence the minor version bump).
v0.11.0
I didn’t make an announcement for that release, however, because it drew me into tackling the two least pleasant parts of the codebase internally and I felt more breaking changes on the horizon. This prompted a lot of activity in the last few months, touching nearly every line of code (although I’m proud to report that outside of initialization functions and formatting none of the doctests changed). This will shortly culminate in penultimate release before the v1.0.0 milestone.
An overview of the more notable evolutions:
-
The signatures for store initialization will change.
The solution I hand-rolled for this in
v0.9.0was in fact unwittingly a sort of ad-hoc version of Elixir 1.5.0’schild_spec, but not similar enough to avoid being fundamentally incompatibly with it. I’m still updating the documentation to reflect this change so I’m afraid you can’t get great insight into the ramifications it by perusing it, but this will be in place forv0.11.0. -
All new Elixir 1.5 features that can be used, are, and support for 1.4 will be dropped.
Aside from full
child_specsupport, all internal behaviours use@impland behaviour-leveldefoverridable, and the handshake between clients and the server uses parameterized types to clean up some messy typespecs. This should make adding new features and stores to Mnemonix even easier as all sorts of tooling will warn if the internal contracts between client and server, and server and store implementation, are not quite met correctly. -
The client builder is substantially more sophisticated.
One of the more ambitious goals I have had in mind for Mnemonix is either getting it into Phoenix, or having it be recommended by Phoenix guides, as the defacto out-of-memory cache and session store utility. Whether or not that will ever happen is completely undetermined but that hope has set the standard for the level of flexibility and rigor that I’ve been pursuing with the project, especially with regards to being used as a configurable intermediary to key/value stores in other libraries.
If for some reason you do not want users of your library to have to know about the Mnemonix namespace, and want to forge a custom API to interact with stores, you can simply
use Mnemonix.Builderinto a module. This module then receives all functions to interact with a Mnemonix store as if it were theMnemonixmodule itself, with all relevant documentation. These functions can optionally be inlined into raw GenServer calls instead of simply delegating to Mnemonix functions, and you can omit their docs if you’d rather. You can cherrypick which feature-sets you want to include or get them all wholesale.You can also build ‘singleton’ functions instead of normal ones—then the generated functions know in advance about a GenServer name for a store your library will be managing itself in its own supervision tree. All the functions in the module using the builder will no longer need to specify a store reference as their first parameter because they will be generated with knowledge of this GenServer name to use instead.
-
The default implementations for all callbacks are trivially testable in isolation.
Mnemonix is, at its core, two behaviours: one that client modules must implement to send commands to a store server, and one that store implementations must meet to understand and act upon instructions received by a server.
Each module using one of these behaviours must define some 35 functions in order to fluently speak Mnemonix, and that’s a lot to ask. Fortunately, these two behaviours can derive default implementations for all of them, save for 4 on the store implementations: an init function, and basic map put/fetch/delete implementations. In order to DRY up the source code, make contributing to Mnemonix easier, and allow custom Mnemonix clients to override behaviour, when you use a Mnemonix Feature Behaviour or Mnemonix Store Behaviour into a module, these default implementations are provided.
People who have ran into me on this forum or on the mailing list in certain conversations might know I’ve long been agitated by the current idiomatic solution for creating behaviours that furnish using modules with default implementations of their own callbacks. This is because the current default approach—throwing a bunch of
defs inside a__using__macro—does not scale well or offer great testability for these default implementations. This is fine for most use-cases but spectacularly insufficient for Mnemonix’s very particular architecture.I’ve created a very particular piece of metaprogramming to solve this pain point that also powers all of the features in the builder tool:
Mnemonix.Behaviour. Both feature behaviours and store behaviours use this module; and every function they define that matches the name of a callback also defined in the module is transferred to any module that uses the behaviour as a default implementation. Crucially, this means that these default implementations concretely exist on their host modules instead of living in an un-compiled__using__void, so they can visibly document their behaviour, emit compiler and dialyzer warnings, and be easily tested outside of where their behaviours are used.The current implementation is Mnemonix specific but I may get around to extracting it into a more general form and publishing it somewhere.
I will release as v0.11.0 once the lingering planned tasks are finished, which I anticipate to be sometime soon after the turn of the year.
v1.0.0
The two main obstacles remaining before takeoff are, as they always have been, performing more extensive testing outside of moduledocs and replacing derived default store function implementations with optimized store-specific versions where possible.
Aside from some extra documentation and tooling tweaks, those are also finally the only obstacles left, and in fact things have been feature-complete and nearly API-stable for quite some time. I’ve talked about those two big hurdles a bit here and on the issue tracker, so there’s really not much more to say. However the preceeding v0.11.0 can be treated as an RC since those remaining issues in no way affect any Mnemonix API or behaviour, and just polish them up.
However, I’ve put together a lot of supporting tooling with an eye to the pending Big One in mind that have taken a lot of effort that I thought I might mention before closing:
- A scriptable credo style guide is pretty much complete
- Dialyzer is happy with the entire project
- Both of those as well as code coverage and documentation coverage are executed in the build process
- The source code is fully formatted with the upcoming formatter
- The dev environment is instrumented with cortex to run tests as files change (and hopefully all of the above, soon)
- There is a wiki on the repo to host user-contributed content and guides should they emerge
- There is a project on the repo for triaging inbound issues and pull requests
I look forward to seeing you in another thread! Maybe I can contrive to drop the Big One on Valentine’s Day to help express the gratitude I have for you all. 
