On Mon, Nov 12, 2007 at 01:00:15PM -0800, David Roundy wrote:
On Mon, Nov 12, 2007 at 02:01:26PM -0500, Devin Mullins wrote:
which is able to compose.) The latter; hrm... how can we have readable state without a readable event hook (cleanly)?
I think the two would need to go together over restart.
Wired together, yes, but is there much chance of an eventHook changing itself? Even a toggle would contain both hooks and state about which hook is selected. So we'd just need a way to tie the event to the state. (By name, akin to how you serialize objects in a OOPL.)
I'm sold on the state thing (so long as it can be implemented cleanly), and you had me at hello with the Message thing, but I haven't budged as regards the Read/Show requirement.
Fortunately, that last also seems to me to be the least important. I'd lean towards including it, since it seems like if you introduce a read-failing event-hook, all you've lost is whatever was gained by introducing the Read/Show requirement. So you don't lose anything by introducing the change (so far as I know).
Grrr. Events were very easy to do -- just intercept the call to handle. Messages come from several places, but (the important ones?) pass through broadcastMessage. However, unhandled Events do, too. Double trigger seems bad. Devin