<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="">On Dec 22, 2015, at 9:08 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">I think there’s value for users in being able to group and scope the components associated with a particular behavior, so IMO it’s worth it. Overall, it makes usage of the language less complex in practice.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I tend to agree. There is definite value in having really independent things scoped out and cordoned off in their own areas.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">On balance I like it too. Going with a behavior decl opens some questions though:</div><div class=""><br class=""></div><div class="">- Can behaviors be extended?</div></div></div></blockquote><div><br class=""></div><div>From an implementation perspective, I’d prefer not. From a user model perspective (which is what really matters :) we want to be able to add methods to them somehow. I think it would be fine to require more boilerplate for this (e.g. the backing store for lazy is actually a struct, and that struct is what gets the extension) - so long as it doesn’t cause boilerplate on the client side. You shouldn’t have to say myProperty.lazy.backingStore.clear(), just myProperty.lazy.clear().</div><div><br class=""></div><div>I don’t know where that leaves us :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Can behaviors be resilient? One nice thing about a fragile behavior is that we can inline its storage, if any, directly into its containing type without having to instantiate metadata for a nominal type, as we would for a struct-based property implementation. A resilient behavior, however, would end up needing more or less the same metadata to encapsulate the layout of the behavior's state behind the resilience domain, weakening that benefit.</div></div></div></blockquote><div><br class=""></div><div>I’d be fine with requiring an explicit struct to be defined inline in the behavior to get resilience.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Should behaviors be able to control their default visibility policy? As Brent and others pointed out, most behaviors are implementation details, but the few that make sense as API generally always want to be API, such as `resettable` or `KVOable`.</div></div></blockquote><br class=""></div><div>I’d suggest defining them to be private by default, and allowing the "var (public lazy)” sort of syntax. After the basic proposal and model is done, we can then talk about adding a “public_by_default” trait to behavior to reduce boilerplate (if it is an issue in practice).</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>