[swift-evolution] [Proposal] Property behaviors

[Russ Bishop]

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).


Russ


> On Dec 17, 2015, at 1:36 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
> 
>> As for combining behaviours... Someone should have to do the work of combining them properly by creating a new behaviour type for the combined behaviour. To make this easier syntactically, we could have a behaviour combination function that would create a combined behaviour type. That function could be overloaded to support only behaviours that are compatible with each other.
>> 
>> Overall, this looks very good. But there is almost nothing said about derived classes and overriding. I very often override a property just so I can add a `didSet` clause, and if `didChange` was implemented I'd use it too. I'd very much like if those property behaviours could be compatible with overriding (where it makes sense). The way I see it, the behaviour should be able tell the compiler whether the overriding accessor should either replace or be prepended or appended to the overridden closure from the base class, or if overriding is simply not allowed.
> 
> Yeah, composition of behaviors and overloading are two areas I'm still working through. Composition is tricky, since it's not scalable to require overloads for all possible M!/N! combinations of behaviors. Any decoupled composition behavior is going to have ordering problems too—lazy-before-synchronized and synchronized-before-lazy would both be accepted, but one would be broken (unless you could blacklist problematic combinations, which also seems like an exponential-order problem).
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/a40f5c68/attachment.html>