<div dir="ltr"><div><div><div><div>Hey Robert,<br><br></div>Well the example I gave was stored properties in extensions - that is they can be easily implemented as calculated properties that actually use associated objects/values to store their value. The other one is per-instance actions, programmers can dynamically add an action (closure) to any instance (for example decide where it needs to be sent and add a closure with the key "send"), then that action can be performed later by retrieving whatever is in "send" and calling it - basically whenever functionality rather than data needs to be moved around.<br><br></div>I agree it's not an efficient or type-safe system, but of course any developer using it is doing so at run-time so they know there's no type-checking going on and should take measures to ensure only the correct types are put into any situation (or check it themselves). It *can* be implemented without affecting the ABI - as my example code shows, I'm just not sure if this is a good way to do it.<br><br></div>I'm not sure what you mean about obj-c associated objects having a slow deallocation path, is there a learning-point from the obj-c implementation that helps here? If so I don't know it :) I don't think you would try to make it type-safe as it's a dynamic feature and you'd expect the users to do that themselves - sure there could be ways to use reflection to help out, but is this necessary?<br><br></div><div>As noted in the README - deinit hooks would enable an implementation that doesn't need to do the internal clean-up. So it works as-is, but could be improved with some language features.<br></div><div><div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 28 Sep 2016 at 19:46 Goffredo Marocchi <<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPhone</div></div><div dir="auto"><div><br>On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><span></span></div><div><div><div style="direction:inherit">Have you got a significant use-case for this that absolutely can't be solved by extensions or subclassing?</div><div style="direction:inherit"><br></div><div style="direction:inherit">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"><br></div><div style="direction:inherit">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></blockquote><div><br></div></div><div dir="auto"><div>If observers, whose lifetime is longer than the the observed objects' one, were notified when the observed object is deallocated then I would agree with you about safety concerns trumping usability... but as it is right now a nice mechanism like KVO is made trickier to use than it should be without associated objects (KVO leakage is quite a scary concept :)).</div></div><div dir="auto"><br><blockquote type="cite"><div><div><div><div style="direction:inherit"><br></div>~Robert Widmann</div><div><br>2016/09/28 11:26、Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><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/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><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>Interested in feedback and thoughts :)<br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div>