[swift-evolution] associated objects

[Goffredo Marocchi]

Sent from my iPhone

> On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution <swift-evolution at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160928/10111cfa/attachment.html>