I mean, I do appreciate the focus on having a symbol that will throw a compiler warning, not just anger a linter

but i'm still not sure about how best to tie "domain model function" to "registered subscription"

I didn’t think it was possible to have the linter detect typos in subscription keywords. That would certainly help avoid this wrapping stuff.

Can you elaborate on “domain model function”? I posted here because I’m unsure myself whether my wrapper is a good idea, so I’d appreciate hearing about your experience.

We did something similar (really for item 1) and it works ok, but an issue can be subscriptions that are more nested/complex. The symbol names get kind of goofy in such cases with -- separators for nesting, etc, to the point where it seems better to just use a vector with a keyword.

> Can you elaborate on “domain model function”? Well, i'm still hung up on how to take the "entire state of the world" and divide it into managable chunks

if you have a single structure - your "domain model" - you can make functions that work with that structure

subscriptions are magic lookup into the global scope and i don't know if the same things you write for a subscription would be good functions for working with a "nested" scope

After using this for a few days I’ve decided that the downsides outweigh the advantages, e.g. I can’t use LSP to find all references, which I can actually do with the plain subscription keyword. I can always pull out an accessor function in the few cases where some event could use the access pattern as the subscription.

Seems this is a common pattern for me. I start thinking “maybe a macro would help here” and I usually end up reverting it!

yeah - at least with what i described earlier with the defevent - the symbol we use the most is the one the linter can pick up

the handler:event-name and event:event-name are more rare to use in the codebase proper and mostly get seen in tests