weak-references

Can you see downsides to this one-liner other than the fact that multiple uses of it would violate the DRY principle? It seems straightforward but the fact that I haven't seen others propose it makes me wonder if there's a downside to it. This bit of code creates a WeakReference to a method and then registers an event handler that invokes the reference's target. SomeEvent += (sender, e) => ((Action)(new WeakReference((Action)ProcessEvent)).Target)(); Thanks, Ben I don't think that pattern does what you expect. Are you trying to prevent the event from holding a reference to the current object

Code: from weakref import WeakSet se = WeakSet() se.add(1) Output: TypeError: cannot create weak reference to 'int' object Doc : Several built-in types such as list and dict do not directly support weak references but can add support through subclassing: ... Other built-in types such as tuple and int do not support weak references even when subclassed (This is an implementation detail and may be different across various Python implementations.). This isn't expressive enough to explain: Why some built-in types don't support weak references? What are exactly those types that support weak

I'm making another attempt today to try to understand retain cycles and weak references in Swift. Reading through the documentation , I saw the following code example where one of the referencing variables is marked as weak to prevent a retain cycle: class Person { let name: String init(name: String) { self.name = name } var apartment: Apartment? deinit { print("\(name) is being deinitialized") } } class Apartment { let unit: String init(unit: String) { self.unit = unit } weak var tenant: Person? // <---- This var is marked as 'weak' deinit { print("Apartment \(unit) is being deinitialized") }

Is there any obstacle that prevents weakref from doing everything that __del__ does but with much stronger guarantees (e.g., finalize guarantees that the call will be made before the interpreter exits, and the order of calls is well-defined, etc.)? It seems that in the distant past it was thought that weakref would eventually lead to the removal of __del__ from the language. What prevented this from happening? There seems to be few use cases for __del__ , and all the ones I'm aware of seem to work at least as well (and usually much better) with weakref callbacks or weakref.finalize . Update:

I'm working on an iPhone application. I have an object of class Row that needs to release numerous objects of the class Block . Every Block currently has a property that retains an instance variable of class Row . @interface Block : UIImageView { Row *yCoord; } @property (nonatomic,retain) Row *yCoord; @end Every Row contains an NSMutableArray of these Blocks. @interface Row : NSObject { NSMutableArray *blocks; } -(void)addBlock:(Block*)aBlock; @end @implementation Row -(void)addBlock:(Block*)aBlock { [blocks addObject:aBlock]; aBlock.yCoord = self; } @end I understand that this is a circular

I am writing a small test program using Xcode 5.1.1, for iOS 7.1. I am not using Xib or Storyboard. Everything is done programmatically. In the AppDelegate.m, I create an instance of my TestViewController and set it as the rootViewController of the window. Inside TestViewController.m, I override the "loadView" to create and assign the main view of the controller. TestViewController.h -------------------- @interface TestViewController : UIViewController @property (nonatomic, weak) UILabel *cityLabel ; @end TestViewController.m -------------------- @implementation TestViewController - (void

I would like to be able to keep track of instances of geometric Point objects in order to know what names are already "taken" when automatically naming a new one. For instance, if Points named "A", "B" and "C" have been created, then the next automatically named Point is named "D". If Point named "D" gets deleted, or its reference gets lost, then name "D" becomes available again. The main attributes of my Point objects are defined as properties and are the quite standard x , y and name . Solution with a problem and a "heavy" workaround I proceeded as described here , using a weakref.WeakSet()

Javadocs says "When a key has been discarded its entry is effectively removed from the map". But unless there is another thread that occasionally removes such Map.Entry entries, won't the value objects be strongly referenced by the map? But since there is no such thread running, only the get method invocations can remove such entries - one at a time. I almost always use WeakHashMap<K, WeakReference<V>> for that reason. Why would they not have made that the default behavior - values as weak references too? Reference queues are used to automatically remove entries. http://docs.oracle.com/javase