This is somewhat of an assertion based on feeling/observation so feel free to challenge but wanted to put this out there.

I don't think ui::Event should have subclasses for specific event types. It's annoying in dispatch code where mostly we don't care about event types, just the flow of events. Where we do, we'd much rather just check a type field so we can route appropriately.

This makes events harder to construct as we need to construct the right type, and in framework clients where we receive generic events we then need to cast back to the right implementation type to call the helper methods.

Instead, I propose ui::Event as a generic uber event, with nullable fields for type-specific data. These type-specific data objects might contain utility functions for convenient analysis, or these functions could just be global utility functions... that's more of an aesthetic decision.

Sky@ points out the value in (e.g.) the Views layer of using types to guarantee OnMousePressed() can only take a MouseEvent, which I buy, but it seems that that could be achieved via a views-specific wrapper which wraps the generic & provides the type-specific convenience functions. I think this makes sense inside the Views layer, but IMO various FooEvent classes makes little sense in the dispatch layers.

WDYT?