> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution 
> <swift-evolution@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@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.

Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to