Sent from my iPhone
> On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution > <[email protected]> wrote: > > Have you got a significant use-case for this that absolutely can't be solved > by extensions or subclassing? > > This does have ABI impact but more concerning for me is the performance > impact and that the existing API is not type safe. > > Using associated objects in ObjC gets you read through the slowest possible > deallocation paths and means the runtime is effectively tracking an extra > table of pointer tables per object-with-associations. 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. If observers, whose lifetime is longer than the the observed objects' one, were notified when the observed object is deallocated then I would agree with you about safety concerns trumping usability... but as it is right now a nice mechanism like KVO is made trickier to use than it should be without associated objects (KVO leakage is quite a scary concept :)). > > ~Robert Widmann > > 2016/09/28 11:26、Jay Abbott via swift-evolution <[email protected]> > のメッセージ: > >> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
