sproutcore/sproutcore — pull request #1151 by publickeating (2013-12-18 22:42:45+00:00)
Title: Core Statechart

This is an incomplete PR that I'm posting to get discussion going. What I've experimented with is to split out the *core* statechart features from the *application* statechart features. The result is the addition of SC.CoreStatechartManager & SC.CoreState within the `:core_foundation` framework. These are meant to be the barest versions of SC.StatechartManager & SC.State, which are still available in the `:statechart` framework, but become extensions to the core versions.

The reasons to do this are:

1. makes statecharts available by default for all objects and views.
This allows for refactoring of many internal object states into actual statecharts (ex. https://gist.github.com/publickeating/4946794). For another example, this would allow me to rewrite the SC.View internal statechart and the SC.ContainerView internal statechart using actual statechart logic, which should vastly clean them up and prevent edge state problems due to the complexity of the number of states. Other candidates are SC.ButtonView and possibly even SC.Record.
2. makes non-application statecharts faster.
If you look at the extensions to the core that remain in `:statechart` after stripping out the non-essentials, you will see that they are either application specific features, like routing, or are niceties that simpler internal statecharts can make do without, like fuzzy event handlers (method vs. string vs. regex event specifications). While an application statechart is only initialized once and doesn't effect performance in a meaningful way, thousands of objects may be created or destroyed per second and so if each object has one, two or even three internal statecharts (ex. view state, enabled state, interaction state), these internal statecharts have to be extroardinarily fast.

So this is a work-in-progress, but I think it has shown some merit *provided that the core versions are bare enough to not effect performance compared to manual state management (i.e. getting, setting and checking flags)*.

I welcome people's opinions on whether to keep going in this direction or not. Thanks.