Hey Robert, Well the example I gave was stored properties in extensions - that is they can be easily implemented as calculated properties that actually use associated objects/values to store their value. The other one is per-instance actions, programmers can dynamically add an action (closure) to any instance (for example decide where it needs to be sent and add a closure with the key "send"), then that action can be performed later by retrieving whatever is in "send" and calling it - basically whenever functionality rather than data needs to be moved around.
I agree it's not an efficient or type-safe system, but of course any developer using it is doing so at run-time so they know there's no type-checking going on and should take measures to ensure only the correct types are put into any situation (or check it themselves). It *can* be implemented without affecting the ABI - as my example code shows, I'm just not sure if this is a good way to do it. I'm not sure what you mean about obj-c associated objects having a slow deallocation path, is there a learning-point from the obj-c implementation that helps here? If so I don't know it :) I don't think you would try to make it type-safe as it's a dynamic feature and you'd expect the users to do that themselves - sure there could be ways to use reflection to help out, but is this necessary? As noted in the README - deinit hooks would enable an implementation that doesn't need to do the internal clean-up. So it works as-is, but could be improved with some language features. On Wed, 28 Sep 2016 at 19:46 Goffredo Marocchi <pana...@gmail.com> wrote: > > > Sent from my iPhone > > On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution < > swift-evolution@swift.org> 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 <swift-evolution@swift.org> > のメッセージ: > > 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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution