In this post:
- A brief explanation of the stuff I was doing instead of documenting refactor targets.
- The refactor targets.
When I was going over the Homunculus code for this post, I realized I wanted to use the matching system in more ways than was possible at the time, in order to replace the "Visitor" classes I'd written, and ideally get rid of some explicit branches in favor of constant data in an iterable form.
At first, I approached this "match extension" concept from the perspective of creating a custom matcher that can specially deal with tdl input events, but as I started working on implementing an API for that, I realized I could get most of the functionality I needed simply by creating a Pattern type that destructures objects by attribute. While I was at it, I designed one for destructuring dictionaries.
In the morning, I'll cut a new minor version, but for now, I slept terribly last night, so I'm going to try to speed through the rest of this post.
I still want to provide an API for custom destructuring logic, but that's not a priority currently.
In tiny music, the initial use would be to convert the NoteType enum to an ADT. Although this is relatively straightforward, I'm going to hold off on doin it because I have type-checking etc happening on that project, and I haven't yet tried to make a mypy plugin to make anything at all involving ADTs typecheck.
On Homunculus, I thought I was going to cover GameStates first, but I think I'm going to go for replacing some of the uses of the Visitor class first. Then GameStates, then the Template concept.
I ought to write up the match semantics of all of this stuff. There are some subtleties that I might potentially forget. Perhaps sometime I should do a documentation pass on Structured Data for a week, but that's not this week.
Next time, I start trying to use this stuff.