<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Dec 25, 2015, at 12:02 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" style="font-family: HelveticaNeue; font-size: 13px; 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=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">when you stuff a lot of functionality into a single class in most OO languages, there’s no real way to enforce its division into subsystems, because every method has direct access to every property and every other method. In contrast, in Swift you can divide that class into distinct components with their own interface, state, and invariants, essentially making each component as good as its own type as far as encapsulation goes.<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">…etc…<br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><br class="">I feel like the strongest argument against allowing stored properties in extensions is the argument that it's poor design to have very complex types. I have two responses to that; I apologize if this seems like straw-manning, because I know you haven’t raised this objection.<br class=""><br class="">The first is that I’m always uncomfortable with abstract arguments against the complexity of other people’s code.<br class=""></blockquote><blockquote type="cite" class="">…<br class=""></blockquote><blockquote type="cite" class="">The second is that this is a valuable tool for incrementally reducing that complexity.<br class=""></blockquote><br class="">There’s a third good argument as well: it decouples API design from scoping of private state.<div class=""><br class=""></div><div class="">I find that readability at the point of API use often pulls against minimizing variable scope. A recent example: Siesta’s Resource class provides “latest best information” about the state of an HTTP resource, and lets you observe changes to that state. It’s nicest to work with the API when the same Resource class provides both of these things:<br class=""><div class=""><br class=""></div><div class=""><div class=""><div style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; min-height: 12px;" class=""><span style="font-size: 10.5px;" class=""> activityIndicator.hidden = !resource.isLoading</span></div></div><div style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; color: rgb(88, 126, 168);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span>displayStuff<span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">(resource.</span>latestData<span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">)</span></div><p style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; min-height: 12px;" class=""> <br class="webkit-block-placeholder"></p><div style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo;" class=""> resource.<span style="font-variant-ligatures: no-common-ligatures; color: #587ea8" class="">loadIfNeeded</span>()</div><p style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; min-height: 12px;" class=""><br class=""></p><div class=""><div style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; min-height: 12px;" class=""><span style="font-size: 10.5px;" class=""> </span><span style="font-size: 10.5px;" class="">resource.</span><span style="color: rgb(88, 126, 168);" class="">addObserver</span><span style="font-size: 10.5px;" class="">(</span><span style="font-size: 10.5px; color: rgb(50, 62, 125);" class="">self</span><span style="font-size: 10.5px;" class="">)</span></div></div></div><div class=""><span style="font-size: 10.5px;" class=""><br class=""></span></div><div class="">However, in the implementation, I would like to expose the set of observers only to the observer-related methods, i.e. the private <span style="font-family: Menlo; font-size: 11px;" class="">observers</span> property should be exposed to <span style="color: rgb(88, 126, 168); font-family: Menlo; font-size: 11px;" class="">addObserver</span><span style="font-family: Menlo; font-size: 11px;" class="">()</span> but hidden from <span style="font-family: Menlo; font-size: 11px; color: rgb(88, 126, 168);" class="">loadIfNeeded</span><span style="font-family: Menlo; font-size: 11px;" class="">()</span>).</div><div class=""><br class=""></div><div class="">Doing that using traditional methods gets ugly. I have to make a separate ResourceObservers type, and then … what? I can make it public, and force this API usage (which looks reasonable at first but rapidly gets awkward):</div><div class=""><br class=""></div><div class=""><div class=""><div style="margin: 0px; font-size: 10.5px; line-height: normal; font-family: Menlo; min-height: 12px;" class=""><span style="font-size: 10.5px;" class=""> </span><span style="font-size: 10.5px;" class="">resource.observers.</span><span style="color: rgb(88, 126, 168);" class="">add</span><span style="font-size: 10.5px;" class="">(</span><span style="font-size: 10.5px; color: rgb(50, 62, 125);" class="">self</span><span style="font-size: 10.5px;" class="">)</span></div></div></div><div class=""><span style="font-size: 10.5px;" class=""><br class=""></span></div><div class="">…or I can make the ResourceObservers type private and follow Demeter’s so-called law to its ugly conclusion, and have a bunch of forwarding methods on Resource.</div><div class=""><br class=""></div><div class="">Those API problems aside, I’m up a creek anyway: there’s _private_ state of Resource that both <span style="color: rgb(88, 126, 168); font-family: Menlo; font-size: 11px;" class="">addObserver</span><span style="font-family: Menlo; font-size: 11px;" class="">()</span> and <span style="font-family: Menlo; font-size: 11px; color: rgb(88, 126, 168);" class="">loadIfNeeded</span><span style="font-family: Menlo; font-size: 11px;" class="">()</span> need to see. Exposing that state to a separate ResourceObservers type is far messier than just letting the Resource class get a little bit bigger.</div><div class=""><br class=""></div><div class="">Some form of “properties in extensions” could help ease this problem, letting extension scope group methods with just the state they need, while still letting us design API based on what looks best from the outside.</div><div class=""><br class=""></div><div class="">This argument might even make the “extension properties” idea a little more compelling for structs.</div><div class=""><br class=""></div></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></body></html>