<div dir="ltr"><div>-1 for me, but...</div><div><br></div><div>> <span style="font-size:12.800000190734863px">I’m aware of how associated objects work, I’m not aware of why they are particularly useful in Swift </span><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">If stored properties in Extensions aren't useful, why would anything else in an Extension be useful either? I gather there are reasons it is impractical to implement them, but saying there's no benefit to them is like arguing against allowing methods in Extensions, or computed properties. </span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">My own reason for wanting stored properties in Extensions, is that it would allow me to organize my classes according to their features. I'm working on drag and drop at the moment, and I would find it much less confusing in future, if I could keep all the related properties and methods I'm creating isolated in a single file. It would also allow me to reuse the same View in other projects that don't require Drag and Drop *as is.* Otherwise, when I reuse the class, I'll have to either carry along stored properties I don't need, or carefully weed them out.</span></div><div><br></div><div><span style="font-size:12.800000190734863px">> </span><span style="font-size:12.800000190734863px">we have to do better than ObjC</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">That's the reason I'm against the proposal, too. If we allow stored properties they should be first-class citizens (assuming that is technically possible, I don't understand enough about how Frameworks etc are compiled to know if it would cause issues). I already avoid Associated Objects because I worry the additional complexity will make my apps harder to debug if there are memory or performance issues, so the thought of baking them into Swift doesn't really appeal to me.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 6:52 PM, Robert Widmann via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 28, 2016, at 11:26 AM, Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div><div><div><div><div><div>I have implemented Associated Objects (and values) in pure swift here:<br><a href="https://github.com/j-h-a/AssociatedObjects" target="_blank">https://github.com/j-h-a/<wbr>AssociatedObjects</a><br><br></div>The README is very short and straight-forward so I won't re-describe it here.<br><br></div>The implementation isn't great, but it's a small and simple proof of concept. I have further extended this (not in GH, but very simple and happy to share if anyone cares) to add dynamic methods using closures onto individual object instances. Useful for user interactions, or adding 'actions' to objects.<br><br></div>I'd like to propose that this or something similar be added to the standard library. It could potentially even be added to AnyObject so that developers can use it without having to declare an extension for whichever classes they want to use it on.<br><br></div>As mentioned, this can easily be extended (either in the standard library or by developers) to add closures dynamically to any object, or to any class, which could serve as a useful way for those not concerned with type safety and the like to get some dynamic behaviour in there in the shorter term. With a little language support it could even be used to implement stored properties in extensions very easily.<br></div></div></div></div></blockquote><div><br></div><div>I’m not convinced by this explanation. You haven’t shown me any cases where this feature is absolutely necessary, merely enumerated features. I’m aware of how associated objects work, I’m not aware of why they are particularly useful in Swift and I’d like to be given something to the contrary. </div><div><br></div><div>As for the point about dismissing type safety: There is no precedent in the language for type-unsafe operations to be exposed wholesale to the end user like this. At the very least you should tag the API as Unsafe Associated Objects and now you’re stuck explaining why you’d like to stick a completely unsafe feature into a language that touts “Safety by Default”. It feels like pining for the Objective-C days of old, and I happen to think that that’s fine, but we have to do better than ObjC, not have features for the sake of features.</div><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div>A better implementation would need some language changes - specifically deinit hooks (has that ever been discussed?) because of the way weak references are lazily zeroed. Another implementation improvement might lazily add the dictionary to each object instead of storing it globally - not sure if this would have ABI implications.<br><br></div></div></div></blockquote><div><br></div><div>That kind of implementation would be space-inefficient - all Swift classes now automatically incur an extra pointer-sized allocation per instance. It absolutely has ABI implications too because now we have to track an extra part of the header for an object and standardize on access patterns for the associated objects table.</div><br><blockquote type="cite"><div><div dir="ltr">Interested in feedback and thoughts :)<br></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>