<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><div style="direction: inherit;" class="">Have you got a significant use-case for this that absolutely can't be solved by extensions or subclassing?</div><div style="direction: inherit;" class=""><br class=""></div><div style="direction: inherit;" class="">This does have ABI impact but more concerning for me is the performance impact and that the existing API is not type safe. </div><div style="direction: inherit;" class=""><br class=""></div><div style="direction: inherit;" class="">Using associated objects in ObjC gets you read through the slowest possible deallocation paths and means the runtime is effectively tracking an extra table of pointer tables per object-with-associations. To make this kind of pattern type safe you would, for example, need to keep track metatype pointers too and use the dynamic cast machinery to check the type on retrieval.</div></div></div></div></div></blockquote><div><br class=""></div><div>Also from an optimization perspective, it prevents any analysis of the side-effects of destructors and causes the optimizer to have to treat all operations that could trigger a deinit as potentially doing anything.</div><div><br class=""></div><div>Given the pervasiveness of release operations, we really do not want such conservatism if we can avoid it. So you really need to balance the need for an associated object against creating a language default that is not an abstraction that one can not avoid in code that is performance sensitive.</div><div><br class=""></div><div>Michael</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><div style="direction: inherit;" class=""><br class=""></div>~Robert Widmann</div><div class=""><br class="">2016/09/28 11:26、Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">I have implemented Associated Objects (and values) in pure swift here:<br class=""><a href="https://github.com/j-h-a/AssociatedObjects" class="">https://github.com/j-h-a/AssociatedObjects</a><br class=""><br class=""></div>The README is very short and straight-forward so I won't re-describe it here.<br class=""><br class=""></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 class=""><br class=""></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 class=""><br class=""></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 class=""><br class=""></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 class=""><br class=""></div>Interested in feedback and thoughts :)<br class=""></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>