<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I started by reading the examples and I was very confused. This suggests to me that if you've never seen a var behavior before, you are going to wonder what the hell is going on. :-)</div><div class=""><br class=""></div><div class="">Notable points of confusion:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">it's confusing to me that `self` is the containing type and the behavior name is the "behavior's self".</li><li class="">The `initializer` special field feels absolutely magic. Has anything else been considered, like an init param that has either a Value or an autoclosure returning one? (If we don't want to capture self, aren't we in for problems capturing self from accessors anyway?)</li><li class="">I see (after reading it) that `var behavior foo<Value>: Value` means that foo "applies to"/"wraps" Value, but I find it confusing to use a syntax more typically associated with "extends" or "implements" or "is a".</li></ul><div class=""><br class=""></div></div><div class="">Questions:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Can a behavior have generic parameters that can't be inferred? Could I write, say, [fooable<Int>]?</li><li class="">What is the tradeoff between `eager` and `deferred`? Is it "only" that `deferred` side effects happen at the mercy of the behavior?</li><ul class=""><li class="">If so, isn't it a problem that behaviors aren't intrinsically explicit about whether they defer initialization? I can see that causing very subtle bugs.</li></ul></ul><div class=""><br class=""></div></div><div class="">Concerns:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">It looks like if you had a [resettable, observable] property, calling resettable.reset() would change the value from under `observable`'s feet.</li></ul></div><div class=""><div class=""><br class=""></div><div class="">Comments:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">While it might be true that square brackets work better with other declarations that could eventually have behaviors, "var behavior" doesn't really lend itself to that kind of extensibility. Are we steering towards "func behavior", "class behavior", etc? Is it a problem if we are?</li><li class="">I'd like to point out that the memoization example is a let variable with a behavior, which is explicitly forbidden by the current proposal.</li></ul></div><div class=""><br class=""></div></div><div class="">Finally, I would like to throw the idea of "foo..resettable" to access foo's resettable behavior (or foo..reset() doing optionally-qualified lookup on foo's behavior methods).</div><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 13 janv. 2016 à 17:07:06, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:<br class=""><br class="">- 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.<br class="">- 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.<br class="">- 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`.<br class=""><br class="">Here's the revised proposal:<br class=""><br class=""><a href="https://gist.github.com/jckarter/50b838e7f036fe85eaa3" class="">https://gist.github.com/jckarter/50b838e7f036fe85eaa3</a><br class=""><br class="">For reference, here's the previous iteration:<br class=""><br class="">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3<br class=""><br class="">Thanks for taking a look!<br class=""><br class="">-Joe<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>