Hey Karl, 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.
On Sat, 8 Oct 2016 at 12:19 Karl <razie...@gmail.com> wrote: > 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 > > 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