[swift-evolution] [Proposal] Property behaviors

Joe Groff jgroff at apple.com
Thu Dec 17 19:23:46 CST 2015


> On Dec 17, 2015, at 3:22 PM, Russ Bishop <xenadu at gmail.com> wrote:
> 
> My first assumption is that behaviors separate broadly into a couple of categories:
> 
> 1. Eager and uncorrelated. The logging example is a good one. A logging behavior probably doesn’t care about anything else, it just wants to run as early as possible to write the log output.
> 2. Ordered or correlated. These have composability issues.
> 3. Un-eager. didSet/willSet kind of behaviors that want to run after all behaviors of type #2 have run.
> 
> I’m trying to think if there is a way to declare the kind of behavior you have and what that would mean for composability and overriding because the compiler would be free to run all behaviors of type #1 first (unordered), then a single #2 behavior, then all the #3 behaviors (unordered), reducing the problem to specifying how ordered behaviors… er… “behave”. Perhaps in that case you’ll just have to manually implement a behavior that calls the desired behaviors. 
> 
> For overriding, as long as there is only one ordered behavior involved, all the other behaviors can execute in the appropriate “phase” without issue (all inherited eager behaviors first, etc).

This is a great analysis. Kevin made a similar observation. If we went in the direction of a dedicated `behavior` declaration, then it'd be reasonable to declare the behavior's kind up front, which would influence its composition behavior.

-Joe



More information about the swift-evolution mailing list