<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="">Joe, your idea for initializer as an accessor makes sense to me. Also, it seems that if resettable's initializer isn't delayed, we don't need the redundancy since it can set the base value from its own init:<div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">public var behavior resettable /* whatever goes here */ {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>eager accessor resetValue(): Value</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var value: Value = resetValue()</div><div class="">}</div><div class=""><br class=""></div><div class="">var [resettable] foo: Int { resetValue { return 42 } }<br class=""></div></blockquote><div class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">Even if I made it up just to support this case, I think that allowing `eager` and `delayed` on accessors might be a good idea. Right now, there appears to be no way to enforce that observed's willSet and didSet do not fire during property initialization. Marking them "delayed" could mean that.</div><div class=""><br class=""></div><div class="">I would support using "initializer" as a special accessor name that refers to the initializer value of the property (parsed as an autoclosure, mapping to whatever behaviors use behind the scenes). Having "delayed accessor"/"eager accessor" in front of it would make it much less magical in my opinion.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">public var behavior resettable /* whatever goes here */ {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>eager accessor initializer(): Value</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>var value: Value = initializer()</div><div class="">}</div><div class=""><br class=""></div><div class="">var [resettable] foo: Int = 42</div></blockquote><br class=""></div><div class="">Chiming in with plx:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">## Request: Declared-Property-Name<br class=""><br class="">If possible, a property analogous to `self` / `parent` / etc. getting at a behavior’s concrete “declared-name” would be amazing, although I know it’s not quite that easy, either (see @objc questions later).<br class=""></blockquote><br class=""></div><div class="">I also think that this is an interesting idea. In fact, when reflection details are better specified (I think that it's in scope for Swift 3, right?), I think that behaviors should have access to the property's "mirror".</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">## Semantics: Overrides + Behaviors<br class=""><br class="">I think this is probably specified somewhere and I just don’t understand it, but I need to ask: how do overrides work for things like the following example:</blockquote><br class=""></div><div class="">Just like right now, I think that behaviors should be completely opaque to subclasses. This means you can't alter their behavior (unless they do a virtual call) and you're possibly not even aware that they have behaviors attached.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">…but if you “expand” what happens within these behaviors, once you have multiple such behaviors in a chain (e.g. `[redraw, invalidateSize]`) you will of course have one `!=` comparison per behavior. Note that although, in this case, `!=` is hopefully not too expensive, you can also consider it as a proxy here for other, possibly-expensive operations.</blockquote></div><div class=""><br class=""></div><div class="">My personal hope is that the accessors will compose and optimize as nicely as short private funcs. I wonder how that would play out with behaviors taken from other modules though.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">## ObjC Interaction</blockquote></div><div class=""><br class=""></div><div class="">I think that this is an issue with @objc. I agree that it should get the name right for boolean properties.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Now going back to a warning when a behavior can alter the property without other behaviors noticing.</div><div class=""><br class=""></div><div class="">We have a pretty small sample size of behaviors, but I predict that it will always be a problem when a property value is set without the whole chain being aware of it. For instance, [resettable, observed] is as much a problem as [resettable, backedByJSON]. Using resettable's reset method bypasses behavior that was deemed useful (or even necessary) by the developer in these two cases. In fact, I would like to challenge you to think of a behavior B with a setter, in a chain [resettable, B], where `reset` bypassing B's setter is what the developer intends.</div><div class=""><br class=""></div><div class="">I think that either one of these should be implemented:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">warn when using a mutating function on a behavior when "outer behaviors" have setters;</li><li class="">ensure that mutating functions send their result value down the behavior chain like a normal assignment (not sure how feasible this is with behaviors that have state).</li></ul></div><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></div></body></html>