[swift-evolution] [Proposal] Property behaviors
felixcca at yahoo.ca
Thu Dec 17 21:00:24 CST 2015
I find that Michel Fortin's idea for subscript-less behaviors is very cool, but it also has an impact on composition. It seems to me that any behavior that doesn't implement a subscript would need to be the outer-most behavior, and it could not easily compose with any other subscript-less behavior.
> Le 17 déc. 2015 à 20:23:46, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
>> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution