Closed 200sc closed 2 years ago
Related to this, if the standard way of interacting with events would involve predeclaring them with compile time typing, we'd be more incentivized to move event names from strings to integers-- one can no longer concatenate events together, so the main argument for strings (which could have been replaced by bitflags anyway, maybe), goes away, and our event library would have improved efficiency.
As another thought, it may be appropriate to have two event libraries, if this new syntax becomes too difficult to use for prototyping / beginners, but I'm not sold either way on that yet.
With the introduction of type parameters for types and functions in Go 1.18, oak's event package could be changed significantly.
Currently, to bind and trigger a binding, one needs to use the empty interface object:
With 1.18 we can do this:
... and granted, all the
Safe
naming in there is verbose, but it would be backwards compatible, and in Oak 4 could be overhauled to consume the existing names.A notable downside-- methods cannot receive type parameters, so working with custom handlers demands passing those handlers in as arguments. The use of non-event handler interfaces is rare, and we don't have a way of enabling this at all, so I'm more or less OK with this trade off.
This would enable us to move all of our event documentation to strongly typed structures, removing empty interfaces from the apparent event interface. Granted we are still using them internally as events pipe around their payloads, a. eventually that interface could be hidden or recommended against using directly and b. maybe there's some more generic functions we could write to remove that as well (although I have not found a way so far).