[swift-evolution] associated objects

Karl razielim at gmail.com
Sat Oct 8 06:19:04 CDT 2016

> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects <https://github.com/j-h-a/AssociatedObjects>
> The README is very short and straight-forward so I won't re-describe it here.
> 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.
> 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.
> 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.
> 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.
> Interested in feedback and thoughts :)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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.

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.

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?).

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161008/26399e5d/attachment.html>

More information about the swift-evolution mailing list