[swift-evolution] associated objects

[Michael Gottesman]

> On Sep 28, 2016, at 9:27 AM, 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.

Also from an optimization perspective, it prevents any analysis of the side-effects of destructors and causes the optimizer to have to treat all operations that could trigger a deinit as potentially doing anything.

Given the pervasiveness of release operations, we really do not want such conservatism if we can avoid it. So you really need to balance the need for an associated object against creating a language default that is not an abstraction that one can not avoid in code that is performance sensitive.

Michael

> 
> ~Robert Widmann
> 
> 2016/09/28 11:26、Jay Abbott via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
> 
>> I have implemented Associated Objects (and values) in pure swift here:
>> https://github.com/j-h-a/AssociatedObjects <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160930/468a3408/attachment.html>