[swift-evolution] Proposal: Weak Native Swift Containers
Tommy van der Vorst
tommy at pixelspark.nl
Thu Dec 10 17:01:06 CST 2015
Hi Riley,
Have you tried using an array of structs that in turn hold weak references to your objects? Something like this should work:
public class Weak<T: AnyObject>: NSObject {
public private(set) weak var value: T?
public init(_ value: T?) {
self.value = value
}
}
let weakFoo: [Weak<Foo>] = [Weak<Foo>(foo), ...]
Comes with the overhead of one extra object instantiated per element, but perhaps this is acceptable for your use case.
/T
> Op 10 dec. 2015, om 23:55 heeft Riley Testut via swift-evolution <swift-evolution at swift.org> het volgende geschreven:
>
> In multiple places in my projects, I essentially recreate the “multiple observer” pattern used by NSNotificationCenter. Originally this was implemented by simply maintaining an array of observers, and adding to/removing from it as necessary. However, this had the unintended side effect of maintaining a strong reference to the observers, which in many cases is undesirable (for the same reasons it’s common to mark delegate properties as weak).
>
> Now, I’m using a private NSHashTable instance, and expose the observers as public API by creating a public computed property which essentially returns an array derived from the NSHashTable like so:
>
> public var receivers: [GameControllerReceiverType] {
> // self.privateReceivers.allObjects as! [GameControllerReceiverType] crashes Swift :(
> return self.privateReceivers.allObjects.map({ $0 as! GameControllerReceiverType })
> }
>
> This workaround works, but is undesirable for a number of reasons. Most notably:
>
> • NSHashTable is not a native Swift collection, and is also not in the Foundation Swift port, so it is not portable to other systems.
> • It also has not yet been annotated with generics, so it loses the nice type safety of other Swift collections. Because of this, I have to map the objects to the appropriate type before returning the allObjects array, which runs in O(n) time instead of O(1).
> • It’s repetitive. For every type that wants to implement this pattern, they must maintain both a public computed method and a private NSHashTable instance. This gets worse when this should be part of a protocol; there’s no way to enforce that each type conforming to it has a NSHashTable, while also keeping that information private from the consumer of the API.
>
> I think native swift collections with support for weak references for their contents would be very useful, and in more places than just listed above. I don’t think Array could be easily extended to support it (what happens if a value is released? does everything shift down? do they keep their indices?), but Set and Dictionary (where the keys and/or values could be weak, akin to NSMapTable) would be good candidates IMO.
>
> Thoughts?
>
> _______________________________________________
> 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/20151211/8005ebeb/attachment.html>
More information about the swift-evolution
mailing list