Robert, What it does is allow developers to extend the language to do things that it doesn't support. Associated Objects is just a flexible way to allow developers to do that, and that's how I used it in Objective-C, so that's what I thought of in Swift when I found that "I want to do <x> but the language doesn't support it". Maybe there's a completely different way to achieve the same thing - but I just went with what I know.
I'm not trying to make Swift more like Obj-C - far from it - I want Swift to ditch all the Obj-C related stuff and be its own thing. It frustrates me to see bad patterns in UIKit (for example) being present in UIKit-for-Swift (I understand why of course, but it's annoying still). Also things like the CharacterSet discussion in the other thread - to me it seems like some of the Objective-C-related implementation details of Swift libraries are leaking out (the language itself doesn't seem to suffer from this though). So it's difficult to come up with concrete examples of "things a developer might want to do but the language doesn't support" because almost by definition they are unforeseen. I can only enumerate the things I have wanted to do in Obj-C and Swift and how I got around it. - Dynamically add properties to a class (obc-c) / implement stored properties (swift). - Add per-instance methods at run-time. - Perform a function when some other object is deallocated (haven't solved this in Swift yet, but in obj-c associated object deallocation is well-defined so I used that). - Other unforeseen things... So maybe Associated Objects isn't the answer and I should have stated the problem better, instead of jumping to what I thought the answer might be... the problem I want to solve is this: As a developer I want to do <x> but the language doesn't support it... what helpful thing *can* I use right now that allows me to achieve this? I accept the disclaimer by ticking this box: [ ] Yes, I understand that I'm not using Swift anymore, but some custom run-time thing that I'm building myself on top of Swift, so if I want type safety I have to implement it, if I want copy-on-write or other optimisations, I have to implement it, and I understand that performance might not be the best too. If Swift can provide something to help developers go beyond the abilities the current version, isn't that a good idea? On Fri, 30 Sep 2016 at 07:13 Brent Royal-Gordon <br...@architechies.com> wrote: > > On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> wrote: > > > > 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. > > Actually, a somewhat different (DispatchSpecificKey-style) design makes > type safety pretty easy: > > import Cocoa > > let myValue = AssociatedValue(.strong, ofType: String.self, on: > NSView.self) > > let view = NSView() > myValue[view] = "Hello, world!" > myValue[view] > > Implementation here: < > https://gist.github.com/brentdax/75bfd619379fea53d8ca8afaa16d95bb> > > Nevertheless, I don't think this should be shipped in Swift; associated > objects are as esoteric as they come. > > -- > Brent Royal-Gordon > Architechies > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution