<div dir="ltr"><div>Hey Karl,<br><br></div>Regarding your comment "It’s unfortunate that it can’t be made more optimal from an implementation perspective" - I think that it can be done in an optimal way, just that the language devs are focusing on other things at the moment. I replied to this thread earlier, changing the subject to "stored properties in extensions" because that's actually what is wanted (associated objects is just one way to achieve it). I have some more to add to that thread so I will continue there.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 8 Oct 2016 at 12:19 Karl <<a href="mailto:razielim@gmail.com">razielim@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 style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8525635550315682665Apple-interchange-newline gmail_msg"></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I have implemented Associated Objects (and values) in pure swift here:<br class="gmail_msg"><a href="https://github.com/j-h-a/AssociatedObjects" class="gmail_msg" target="_blank">https://github.com/j-h-a/AssociatedObjects</a><br class="gmail_msg"><br class="gmail_msg"></div>The README is very short and straight-forward so I won't re-describe it here.<br class="gmail_msg"><br class="gmail_msg"></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="gmail_msg"><br class="gmail_msg"></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="gmail_msg"><br class="gmail_msg"></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="gmail_msg"><br class="gmail_msg"></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="gmail_msg"><br class="gmail_msg"></div>Interested in feedback and thoughts :)<br class="gmail_msg"></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"></div></blockquote></div><br class="gmail_msg"><div class="gmail_msg">I think that being able to retroactively associate data with some other data is extremely important. It’s unfortunate that it can’t be made more optimal from an implementation perspective, but it simplifies so many problems were you would otherwise associate data by keeping parallel collections of indices or whatnot.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I would like it if extensibility was built-in to types in Swift; that their internal layout reserved a pointer at the end, which could point to a dictionary or some other data.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Really, when it comes to retroactive extensibility, it’s incredibly strange that you can add functions but not data. If we were inventing a language without caring about the implementation cost, we would be able to, obviously. I actually don’t think the cost is all that high, and perhaps there are ways that the compiler could still optimise it (perhaps assigning each value an index in an array, rather than a dictionary?).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If we actually want Swift to be this amazing programming language which can scale from scripting to systems programming, we definitely need a way to arbitrarily tag objects. Lots of people won’t use it, and that’s fine, but there are times when you really need it and in those cases you wish you were using a different language.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Karl</div></div></blockquote></div>