[swift-evolution] [Proposal] Property behaviors
plx
plxswift at icloud.com
Wed Jan 13 19:12:00 CST 2016
Quick Q1: is it the case that `var behavior redrawing<Value where Self:UIView> : Value { … } ` would work or no? I’d assume so, but I don’t think there are any examples with a non-protocol constraint on `Self`, making it hard to tell at a glance.
Quick Q2: is there anything you can do in this scenario:
// w/in some behavior:
mutating func silentlySet(value: Value) {
value = value // <- probably not going to work
self.value = value // <- not right either, `self` is the behavior’s owner, right?
}
…other than change the argument name to avoid conflict?
Remark: it definitely feels a bit odd to be using both `Self` and `self` to mean something that’s neither consistent with the rest of the language nor, really, to mean `Self` (or `self`).
I get not wanting new keywords, but this feels like it could be an economy too far; perhaps I’m misunderstanding some aspect of how it’s meant to work.
> On Jan 13, 2016, at 4:07 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>
> Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:
>
> - Instead of relying on mapping behaviors to function or type member lookup, I've introduced a new purpose-built 'var behavior' declaration, which declares the accessor and initializer requirements and provides the storage and behavior methods of the property. I think this gives a clearer design for authoring behaviors, and allows for a more efficient and flexible implementation model.
> - I've backed off from trying to include 'let' behaviors. As many of you noted, it's better to tackle immutable computed properties more holistically than to try to backdoor them in.
> - I suggest changing the declaration syntax to use a behavior to square brackets—'var [behavior] foo'—which avoids ambiguity with destructuring 'var' bindings, and also works with future candidates for behavior decoration, particularly `subscript`.
>
> Here's the revised proposal:
>
> https://gist.github.com/jckarter/50b838e7f036fe85eaa3
>
> For reference, here's the previous iteration:
>
> https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3
>
> Thanks for taking a look!
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list